Embedded - 260: We Talked a Lot

Episode Date: September 14, 2018

Christopher (@stoneymonster) and Elecia (@logicalelegance) talks about vacations for learning and hobbies then answered listener questions. Chris’ toys include the Prusa I3 Mk3 and the UAD Arrow. Elecia likes Camille Fournier’s book, The Manager’s Path. She also got to plug her own book, Making Embedded Systems: Design Patterns for Great Software.   Pacific spiny lumpsucker (Eumicrotremus orbis) at the Seymour Science Center

Welcome to Embedded. I am Elysia White, here with Christopher White. And it's just us this week. We're going to talk about vacations, books, and listener questions. Sounds exciting. So let's start with vacations. Okay. I hear you had one recently.

Sort of. Sort of you had one recently. Sort of. Sort of a half a vacation. Well, I gave you my cold. What more do you want from me? And some rodents. Oh, yeah. Okay, so what were the good parts of your vacation?

So I wanted to work on some projects. Yes. The list was long. Well, I tried to keep it manageable. Yeah so i bought a 3d printer yes and what kind of 3d printer was it well i had had the el cheapo uh monoprice monoprice mini select two i think or maybe it was maybe it was a two and we'd played with that for a little while and it worked for a couple of prints and then it just started not working very well. And I'm, you know, 50% certain the problem was me and I just don't know how to,

didn't know how to baby it properly. And then you gave it to me and like none, nothing worked for me. So I think it, I think it was just, it's, it's an okay printer. I think if you're willing to fight with a lot of things that could make your prints go wrong and i decided there were a lot of things i wanted to print um for like synth stuff and parts and airplane stuff uh and and just learn also how to design things um that okay that, okay, I wanted a real 3d printer, not that the other one's not real, less real than others.

Um, so I got the Prusa I three mark three, which is the new version of the Prusa printer. Um, which I'd, I'd looked around for almost a year or two trying to decide if I was going to get another one. And I looked at some of the other ones. There was the Taz Mini, I think, and some others.

And they're pretty expensive. So after reading around and looking at the Prusa and seeing what people did with it and the features it had, it seemed like it kind of struck the right price functionality and quality sweet spot. And it was around, I think it was around $800 for the kit, which is still expensive, but the Mini Select i3 was $200. And after you've bought three of them, because they keep failing,

that didn't happen. So anyway, yeah, so bought that and got the kit and it took me what do you think two solid days maybe two and a half solid days two and a half or three uh to build it it was sort of challenging it was interesting he kept saying do you think this uh this motor's right and i look at it like, I haven't read any of what you've read. I have no idea. And then he would turn it around and he'd rock it for a little while until I thought maybe he was treating it like a baby. And then he'd turn it around again and he'd rock it a little while.

Well, there was a leveling step early on where you had to make sure it was flat. And if you failed, you had to rebuild it all. There's not a lot of actual flat surfaces in someone's house yeah i try table and like well if i turn it a different way it doesn't rock the same way so the table can't be flat and i tried a different table and it would act different uh finally we found a we had a piece of stone it's a pastry marble yeah so that was reasonably flat so um's 750 kit, 1,000 assembled US. So some of the cool things about it that really made me want it over some of the others is bed leveling was such an annoyance on the Mini Select 2. You have to, there were thumb screws, and you had to add a piece of paper, and it was really a pain.

This does the bed leveling before we print automatically, and it can handle all kinds of warping of the bed. So it takes nine points and then creates a grid that's warpable. The bed itself is magnetically attached, so you can just pull it off when the print is done and twist it to free the print or replace it really easily. So if you want to change surfaces or have a whole range of surfaces, that's pretty easy to do. It has a bunch of other safety stuff, like it has a little, I think it's a little mouse sensor, actually,

that they used, that where the... Optical sensor? Mm-hmm. Okay. Where the filament goes into the extruder, and so it can see that the filament's moving, or if it's jammed or stopped,

and tell you there's a problem. It can auto-load and unload the filament. So it's jammed or stopped and tell you there's a problem it can auto load and unload the filament so it's just got a lot of nice it takes care of a lot of the stuff that could go wrong for you there's still some calibration you have to do but it's way easier than some of the more manual ones so anyway we've done several prints um and they've all come out except the ones that i've kind of been the first ones that I've designed that I'm breaking the rules and don't really understand certain things about how to make objects for 3D printing actually printable. Well, let's see, you printed the frog off of the SD card. That was cute.

And then you printed me a 3D coordinate frame for robotics from Thingiverse. Wasn't there something else from Thingiverse? Yeah, the butterfly. Oh, a reticulated butterfly. Because I'm just fascinated by the idea that you can have hinges and gears printed in place. That was neat. And then you started to build some of your own ideas. What were you using to build them? I tried a bunch of things. So,

just Tinkercad, which is, I think, from Autodesk. Is that what you did the bowl with? It's just a web-based, no. Okay.

I don't remember which. I did the bowl. No, I did the bowl with Fusion 360. Okay. So, Tinkercad. Tinkercad,

which is like a baby version of Fusion on the web, which you can do a lot with. Started with that, played around with that, and then played with Fusion 360 and ended up finally realizing that, okay, there's something to watching YouTube videos. Every time I start with these, I just want to read something and it's i know and so i found some youtube videos for fusion 360 for the kind of thing i wanted to build so instead of saying okay i'm going to do the fusion 360 tutorial from the beginning which i tried for a few minutes and i was like but i don't care i want to build the thing i want to build so i kind of looked on youtube for the object closest to the thing i want to build. So I kind of looked on YouTube for the object closest to the thing I wanted to build and found some videos of tutorials of how to do that. And it turns out they were basic enough that it was pretty simple to kind of pick up enough 360 while watching this and be able

to modify it to what I wanted. So it was just a bowl for holding a plant in a larger pot. But I made some special designs on it. And that didn't end up printing properly because I think I had a lot of overhangs that were just not possible. Well, the first one printed fine because it was a solid bowl. It was just too small because we'd measured it wrong. Right, right, right, right. And then you didn't want it to take forever to print. So you opened it up in like this pretty spiral pattern but then that had overhangs and didn't quite attach and then you printed it upside down

no I modified it and then printed it upside down and it mostly came out so there's a lot of it's hard because you're not just learning the program, the CAD program you're also learning well it doesn't matter how capable I am of designing something that looks the program the cad program you're also learning well it doesn't matter how capable i am of designing something that looks nice in the cad program it may not

be printable on any printer it's not just this particular printer can't do it it's for any kind of um filament based printer it's they can't do certain things. It's funny. In electronics, when you're making a board, you do all your schematic and you do your Gerbers, and then whatever manufacturer you're going to go to, they have design rules. Yes. You essentially need the design rules for this printer, and it should whine at you when you have sliced something it can't make.

Some of the slicers, so the slicer that comes with the printer is a very, you know, it's a common slicer program that they've put the right printers in. What's a slicer program? A slicer program takes the CAD model and turns it into layers. So as the 3D printer deposits layers of plastic, you know, it does one at a time on top of each other. So the 3D, the slicer takes the 3D model and generates layers out of that, and then it generates the movements of the extruder head. And so if you had, like, a mug you were making,

and you get to the part where the mug handle goes out. Yeah. The slicer at that point has just been printing circles. Yeah. And then now it needs to print a circle with a bar on it, which is where the mug handle is going to go out. Yeah. But in physics, in the real world, there's nothing holding up the mug handle. And that can be bad because this is hot plastic attaching hot plastic and so it slumps. Yeah. It turns out there

is something holding it up and that's the previous layer. You can have some overlap and the general rule seems to be 45 degrees so you can have something unsupported going up at a 45 degree angle because there's enough of the previous layers plastic to just come over halfway and then print another okay so you can cantilever you can cantilever things but certain printers are better than others certain uh resolutions are better than others so it's tricky to figure out exactly what works. If your slicer was slicing very thin, it would be easier than if your slicer was making big steps.

Yeah. Okay. And there's actually prints you can get on Thingiverse that just test this, and it just goes to increasing levels of cantileveredness until it fails. And then you pick it up off the printer and say, okay, my printer can go to 60 degrees under these conditions. So anyway, there's stuff like that it's um it's tricky and then i i don't know why but i decided okay fusion 360 oh it was kind of annoying i had a lot of crashes with it yeah you were complaining

about a lot of crashes and not just crashes but just hangs. Like it would beach ball and just sit there for minutes at a time after doing what I thought were simple operations. So I thought, well, maybe I want to look at some other things. And I picked up Blender, which a lot of people use. And I didn't realize how powerful it was for 3D printing stuff. This was super confusing to me because I've just started using Blender in a client project. And there's Chris learning it.

And I'm sitting here going, hmm, I should be learning that too. Or I can just run it. And it was weird, but you, okay, Blender. Well, I saw that people were using it for regular CAD stuff, like making mechanical parts and drawings, just like they were in 360 so uh figured okay the blenders blenders free free it's been interesting in the past to me i think i tried to learn it like five or six or seven years ago for games or something yeah around the time we were playing

with unity no way longer than that okay unity was last year oh my god two years ago um and i think those first versions were just inscrutable. And this was the days before YouTube was like the tutorial haven. So I gave up really quickly on that. But yeah, I decided, okay, this time I'll pick a tutorial and actually go through it. So I spent some time with that. And it was not as bad to get proficient with Blender as it was before. It's still a weird program, a lot of weird choices.

The UI is extremely overstuffed and there's a lot of keyboard shortcuts and things. So it's kind of the, I don't know, it's kind of the Unix of... It's the VI. Yeah, it's not quite as bad, but it's sort of VI of the CAD programs. Or the other ones kind of lead you by the hand. Oh, you would like to do this. Well, that's in a drop-down menu.

So, yeah, so going through that. And I ended up, I haven't done any 3D printing stuff out of that, I think. I can't remember. You started to print that donut thing you made. No, I didn't. Oh, I thought you at least sliced it oh yeah yeah no no i did so one of the tutorials has you make this 3d scene which is all nicely rendered of a donut and a cup of coffee with sprinkles and stuff uh and as part of it the

tutorial shows you how you can apply some of the warps and stuff so i took a warp and applied it to the donut and made it this kind of abstract arch thing. And I said, oh, let's try to print that. It didn't print, but it had lots of overhangs and stuff. Probably at a different angle it would print. So I could try that at some point. Yeah, I spent some time with that. It was nice to just kind of do something completely non-work related with computers for once and not feel like,

you know, well, I've already spent several hours with the computer today. I'm done with it. well, you also spent a lot of time with computer and your guitar. Yes. Yeah. I've been working on the second cover song,

which is coming along. Almost done. They were supposed to come out monthly. That was dumb. You know how, how it works with schedules well i don't well maybe if you hadn't chosen an impossible song well no i took a lot of time off too so i wasn't feeling great and uh i did other things and couldn't get into it so because it was an impossible song it's not that impossible and I basically started over on vacation. So I've spent a few days.

Having learned the song. Okay, yes, the guitar was hard. And I've learned the guitar now. Yeah, because you weren't a guitar player before. No. Okay. I just want to point out, what was the gadget you got that you liked so much that let you play on the couch? Oh, so that's

an audio interface. It's from Universal Audio. Basically, an audio interface is something that takes a guitar input or a mic input and then converts the signals into digital and puts them in your computer into the software.

There's a huge wide range of how capable or how expensive they are. Some of the things that are good about good ones are they have good analog circuitry, so they sound really nice doing the conversion. Some have other features. Lots of inputs, for example. This only has two inputs. I wanted something that I could work outside my studio, like working on guitar to sit on the couch or outside. Um, so this is one of the few that's bus powered. So it's USB-C and, or Thunderbolt

three, but USB-C connector. Um, and it, the computer powers it completely, even though it's got amplifiers in it. Um, so that's really nice and it's pretty compact and it's also got a dsp in it so it does some does some special stuff uh to emulate analog gear uh it's a uad arrow so yeah that kind of guilted me into working harder once i bought it i had to use it so well you did seem to enjoy being able to be wherever you were to to do stuff instead of having to be in your basement laboratory it's okay in the basement laboratory it's just it hadn't it hasn't been sunny for a long time so so foggy it's hard to be in the basement where the sunshine does come in if it's sunny, but does not if it's not sunny. It gets cold down here.

And it gets cold. So, yeah, I bought myself some presents for vacation. It was vacation presents. Staycation presents. Staycation presents. Oh, let's see. And we had big plans to go places but then i got sick so we didn't do much we saw a weird play we went up to pacifica and saw a pretty ocean and

oh we went to the seymour science center yes the santa cruz thing um it's a small aquarium and science center and there are a bunch of bike paths and it'd be nice to hike there and it was just really ridiculous because we went on like a wednesday afternoon and we were the only ones there it was like us and all of the docents the docents kept throwing facts at us except you never want to play marine biology facts with me. Because I love marine biology, and I read about it all the time, and I cannot identify the difference between a moon jelly and a sea nettle. Of course I can.

But there were the spiny lump suckers. Yes, the Pacific spiny lump suckers. Those were new to me. They looked hilarious. They're like Simpsons cartoons ofers. Yes, the Pacific spiny lump suckers. Those were new to me. They looked hilarious. They're like Simpsons cartoons of fish. Yes. They're perfectly spherical. And they have like a giant sucker on the bottom.

And they just bounce off rock to rock. Hover bounce. Yeah, it isn't swimming. They're like three millimeters wide. And they're like a couple inches around. So they look ridiculous. There'll be a picture in the show notes, because they were super ridiculous. This has nothing to do with embedded computing.

Oh, it was your vacation. For Christopher's vacation, I mostly worked. And then you were sick. And then I was pretty sick, yes. So, yeah. It was fun. The mostly worked was for like three days. Really?

Yeah. Well, no, because towards the end, I started working again. Okay. Yeah, because I built some hours last week. I also read The Manager's Path, a book by Camille Fournier. And it was kind of cool. It's about, she was a technical manager. She was a, she was an engineer. And then she became a manager, and then she became a director, and then she became a CTO. And a lot of people want to know, how do you go about this path? What do you need to know to stop being an engineer and start being a manager? The funny

thing is that she starts from a point of, you're an engineer and what do you do? How do you mentor people? How do you become a tech lead? What should you expect from your manager and how do you help them support you in your career? It is the book I wish I had had because HP rushed me into management. I wasn't ready. They gave me nice classes, but I was... Wait, you were a manager at HP? Well, they kept trying.

Oh, okay. And then I kept leaving that group until I went to labs, which they stopped that there. It just, I really wish I'd had it because it answered so many of my questions about, is my manager ignoring me? Why is my manager ignoring me? you expect and how to deal with your drive to micromanage people. It was good stuff. I mean, I don't always like the manager books. I don't even usually read the manager books because, I don't know, I've done that. I don't know what they're going to tell me. But I ended up highlighting a lot of stuff, not necessarily because it was new to me, but because she said it in ways that I just wish I had said it that way,

or that I wanted to make sure I kept because I knew it was advice I would want to pass on. There was one thing that I picked out today. And from managing a team in that section, it's valuable for everyone to realize that they can and should focus on the things they can impact and change and ignore the things they can't. Drama in the workplace is usually little more than ego-entertaining drain. I just, I mean, I have felt that way. But how do you express to someone that that's what you think is happening and that you don't want to participate? There were lots of things like that.

So, yeah, anybody out there who's like, well, how do I become a manager? Or am I doing this right? She had really good advice, really concrete and tactical advice. And it was pretty modern, right? So she talks about Agile and stuff in there. Yeah, but it's not an Agile book. Right, right. When she talked about some of the problems, I thought. She talked about Agile. Or things that could be problems.

From a managerial perspective. and I suspect some agile people, as with any agile implementation, will say, you're not doing it right. But her position, if I recall correctly, was that agile is great for a tactical, everyday sort of thing. But that doesn't mean that as a manager, you give up your responsibility for long-term planning. You still need to set a direction. And that direction then is fulfilled with smaller tasks, which means that you need to be able to break up tasks or to help your engineers learn how to break up tasks themselves. And so it was a big, yeah, Agile is fine and great and all of that, but it doesn't stop direction planning. It doesn't stop planning.

This is still something we have to do. Waterfall has a planning step and Agile doesn't. That doesn't mean you can't look ahead. So, yeah, but it wasn't Agile specific. What I'm saying was it's not like people wear something that's 30 years old

and, you know, written in a context that's no longer necessarily the way a modern company tries to work or says they work. It's true. I mean, reading people were super depressing because they said all the things that we wish were happening now, like don't work in open offices.

Yeah. But I also like the fact that she was very specific about engineers, software engineers, and that that is a different path to go through than managing through other teams. Okay, so listener questions? Sure. I guess the first one's pretty related from Peter. And he started his career in 2013.

Says nice things about the podcast. Thank you. Started a job as an embedded software developer and wants to go into a project management role. He's excited. He's educating himself on the topic of project management, software project management. But what about embedded project management? He's already been through Peopleware. He's currently reading The Manager's Path. Yay! And also has The Mythical Man Month in his pipeline.

But none of these deal with the problems of embedded software because how do you deal with hardware? And how do you deal with Agile as it applies to embedded systems? How do you make a sprint for writing a driver for a spy on an IC if there's a bug in the MCU's spy and the errata is updated only after you have figured out the problem? Or you make a prototype and suddenly the MCU is no longer in stock. How do you be a manager for these kinds of things? Glib quick answer is you adapt. Yeah.

Pretty much everywhere is trying agile now once you're above two or three people. So I think you're likely to have to figure out how to make project management work within the context of agile and embedded systems. This is something I'm pretty familiar with, and I don't have good answers, just that we kind of muddle through.

There's a great deal of the software that is not subject to these kinds of problems. Once you get the project going, once the hardware is finalized, once you have prototypes or something that you're building the firmware against, the kinds of problems he's talking about should be outliers, things that happen half a dozen times in the course of a project or less, right? They can be schedule killers. Well, yes, they can be. And that requires some of the planning up front to kind of recognize things that might be potential schedule killers and have backup plans.

And this all goes to planning. We've had things like that where, yeah, and I was just thinking about this today in the context of Agile. What do you do? You've got this whole thing with a complicated board with many chips from different vendors. Vendors don't necessarily, they're not involved in your process. They're not involved in your Agile agile they don't care about your planning except you know to hit the dates that you tell them to produce a new revision or such or that you know we need production by a certain day uh so what do you do if you've got something you just can't figure out and test-driven development isn't going to help you if you

know you have a bus issue, right? Where you just don't know what's physically happening between the CPU, your software, and some peripheral that you buy from somebody else, where timing is just weird, something's not right, and maybe there's 50 parameters that drive it. I defy anyone to tell me how to apply test-driven development to solve this problem because you're not in control of everything. You can't make a mock of an accurate display bus, for example. So these are the kinds of things you just kind of have to expect to happen. In this particular case,

it took several months to figure out what was wrong going back and forth with the vendor and a bus analyzer. And there are often extremely hard problems that you cannot plan for. And so in some ways, you have to expect the unexpected. And you can't let the process be so cranked down that those things will destroy you. And it's like any electronics project where you're making a custom chip, for example. You always put in the schedule for a re-spin, unless you're insane. Well, indeed.

I've worked for insane companies where they didn't do that, but you always say, well, we're going to get the stuff back back but we're going to have to do a respin so you have to we're going to pad the schedule by that much um yeah you get the engineering prototype you get the production prototype you get the first articles and then you finally ship But those are all hardware and software and mechanical cycles. They don't, you don't say, well, here's my hardware, here's my minimum viable software, and let's ship that as soon as it's done. You have to have a proof of concept or prototype to start with, because if you don't, the risk

in your schedule is such that it may not ever happen it may not be possible yeah well i think that gets me sometimes is the idea that well if we just divide this into small enough steps an unknowable thing becomes solvable right if we divide this into small enough steps then us not being able to figure out how to get this bus to communicate properly well you can't there's there's at a certain point some problems are not divisible you can't say okay we're doing agile so every problem needs to fit in a sprint and preferably half a sprint so you can get more than one done okay but taking the bus analyzing problem again that took three months of just fighting and taking

results and seeing what the bus did you're not dividing that's not subdiv it's not divisible so how do you account for that you can't so somebody goes outside of agile for a while to go solve that problem is what happens and that problem like many of these other problems that are unknowable are the interdisciplinary issues yeah is that the right word yeah yeah where you have hardware and software integration and you have physics and you have mechanical and you have acquisitions where you have to buy things. And one reason to make a prototype is to test all of these people can work together and learn to communicate. As well as the need for having prototype hardware and prototype software and prototype mechanicals.

They may not all work together. I mean, a lot of times the mechanical people will make a looks like or a works like without making an actual fits on the prototype hardware. But the idea with the project management for embedded systems is you need to have those extra integration cycles to discover the interdisciplinary issues. It's not a software

problem. He's got a couple specific questions here, too. Like, how can you make a sprint for writing a driver for a SPI IC if there's a potential for a bug in the MCU's SPI and the errata is updated after a few months? Well, for SPI IC, your driver, if you's a potential for a bug in the MCU, spy and the errata is updated after a few months. Well, for a SpyIC driver, if you're architecting it correctly, you're going to have some abstraction.

So you should be able to write the bulk of it without the MCU involved. So you can certainly plan for and do the agile process around the parts of that that are not tweaky and dependent upon an errata for an mcu i don't think that particular example blows up agile because if there's an errata for the mcu something doesn't work then okay that's a new bug you go plan that and fix that but like your bus issue you don't know where the bug is yeah but yeah I guess. Yeah, but... Yeah.

Yeah, that's probably a similar example. I just... I think there's... And for the bus issue, we had a display driver that was mostly finished. So I guess that was done with. I guess what I'm saying is you can still do Agile for the... You can't...

You shouldn't just throw it out because these potential issues exist. Because the bulk of the work you're going to be doing is not constantly being you know blown up by intractable problems with vendors you know going back to the manager's path uh she suggested that almost all projects have 20 percent in system improvement i don't remember what she said. It wasn't refactoring, but it was paying back your technical debt. Yeah. And embedded systems, I think, maybe needs another percent that is anticipating integration issues.

Yeah, integration has been my hobby horse for decades now because I've been on tons of projects where it's just not planned for. It's like, okay, we write the software and the hardware comes back, and then the next week, everything's working, right? If only. And the other question he has is, you make a prototype and suddenly the MCU is out of stock. Well, don't do that. Try to talk to the vendor.

You're kidding. I mean, you make a prototype, the MCU is out of stock, and then you go to production. That's a mistake of procurement. Exactly. And it's a mistake of choosing your MCU. Ideally, you choose an MCU that's in the middle of a family if you can. And then you have the option to go up or down in the family later in the development process. And you should be checking the MCU stocks when you do your prototype, if you're betting the company on it.

You should be talking to the vendors if you're going to buy more than $10,000, maybe even less. And you just... There is no band-aid. It's time, and time is money. And schedule... There's no software methodology that applies to project management.

That's actually... Yes. I mean, we are talking about sort of different things. And I think Agile kind of tries to bleed into project management. God, that always cracks me up. Agile was and always is, and people are going to yell at me maybe, a software development methodology, right? For the most part. So despite the fact that it's kind of bleeding into how projects are managed

i think that's a mistake and i think you can compartmentalize things such that the project management is dovetailed with the software development and but they don't necessarily operate under the same principles but yeah you're gonna have to adapt we've all been doing this stuff forever and nothing ever works right but it does usually eventually work does it my stuff does i say that my project's currently in parts all across my desk it does work but it's the same problem over and over again. Management is desperate to have something out by a certain date. The date is too aggressive.

It can't be done. And everybody else tries to scramble to make that happen. And if you're lucky, it happens three months later. It's about time and money and features and having only one of those, two of those maybe. Yeah, yeah. Okay, so let's go. But we don't have any resources to point him at. I don't have any resources to point him at.

I pointed him a little bit at my book because I have a chapter where I kind of discuss the integration issues. But then when I looked, it was barely a section. So that was not that great. Well, since we're on the topic of my book, we got an email from Tyler, hardware guy taking a Udacity course on software design processes. They mentioned design patterns, and he thinks of them mainly for non-embedded systems question for us do you all use design patterns if so which ones do you see the most any resources for a hardware guy trying to learn the ropes of design patterns with special regards to the

embedded world i do not sign patterns tend to be associated with object-oriented programming. I don't see a lot of C people talking about design patterns explicitly. I know you're booked it, so we'll get to that. It's the subtitle of my book. I'm not saying that you shouldn't. I'm not saying your book doesn't talk about this stuff. I'm saying the people I talk to, the work I'm doing, it does not come up explicitly. It comes up explicitly occasionally for me. A subscriber, publisher. Sure. Okay. Okay.

That's right. Yeah. Source and syncs. Okay. Okay. That's right. Yeah. Source and sinks. Okay. And some of the buffering things that we just take for granted now. I guess it's possible that they've just become so subsumed into the fabric of how we do things. We don't talk about them as explicitly designed patterns. I think that that's what happens.

I think that the thing that was most important about design patterns, about software design patterns, was the idea that there are common problems seen across different things. And there can be canonical solutions that we don't have to rediscover each time. And that was one of the reasons that it was part of my book. It wasn't like the whole book was, here's one pattern, here's another pattern. It was just where it was appropriate,

I made sure to point out this was a design pattern because it's important to talk about the commonality between software, between embedded software, web software, C++ software. We should stop inventing the wheel. And if you're interested in design patterns and you have tried the Gang of Four book, I have to say I liked the headfirst book quite a lot better just because it was easier to read. I mean, it's longer and it's fluffier,

but in the end, you come away with a lot of the same information. I'm finding I'm doing some app work now. And it's weird coming from pure old stylestyle C embedded because design patterns are talked about just so explicitly all the time in app and web stuff. There's whole frameworks devoted to particular design patterns,

like the React framework, I think, is all about the observer design pattern. That's it. It's a framework about, correct me if I'm wrong, people, but from my limited work with this, these things keep popping up. It's like, oh, this is a factory thing, and this is this, and it's just so explicit.

And that seemed to take hold in that world almost as soon as those things kind of were written about. And it hasn't filtered down to embed it that much in an explicit way. Yeah, we don't talk about decorators. I know in my book, I actually talked about flyweight because it's a really good way to do bitmap systems. But I've never called it that.

And I've seen lots of other people use the same bitmap system. Nobody ever calls it that. There's model view controller. Sometimes you see that in embedded systems. Yeah. Because you want to separate your view from your algorithm. That's going to get it eventually. Yeah, schedulers, thread pools, read-write locks,

there are just a ton of these. But I am maybe not as up to the date as I was before, and I'm kind of bummed because I really do think that this is a way of cheating at developing. It doesn't help you. It's not cheating. Well, no, it's a way of getting better at developing. It's expanding our language of things that we do commonly.

Yeah. Because design patterns, I mean, they're patterns. They're things that occur repeatedly without us trying to right so like i don't know a circular buffer and and implementing that as part of your uart um that's a design pattern that comes up over and over and over again nobody called a design pattern until maybe your book. But I don't think anybody's gone kind of retroactively throughout

embedded systems and said, okay, well let's look... let's make a formalism around this, like the Gang of Four did. Yeah. So I think that's what's missing. It doesn't mean the design patterns don't exist. The design patterns exist with or without us giving them names or formalizing them.

Well, an iterator is one of them, and that's something we talk about. Yes, but that's usually associated with parts of languages that have iterators built into them. I mean, C does not, unless you count a for loop which is not an iterator it is a it's a conditional one of you iterator it's a flow flow control a program flow thing so yeah i guess we don't get as many design patterns because they're not built into the language they're not built into the language and we have other things we have to learn like maybe if you did software 100% of the time and you didn't have to read the data sheets for everything you have to deal with you'd have more time to read a computer science book to give you these names I don't know and there are

debugging patterns now and architectural patterns and all the things that, I mean, they've tried to make that go further, but the design patterns themselves are pretty good. I did enjoy reading that headfirst book. And if you are doing embedded systems and you are unaware that I have a book, I do. It's called Making Embedded Systems. That's just so I can say, I wrote the book on making embedded systems. Which I really try not to say because every time I say it, I crack up afterwards.

Okay, how about the question from Danny? I'm a college student majoring in EECS. I first got into embedded programming because of its applications, robotics, automotive, yay. And I'm really interested in a lot of other theoretical topics in such areas as control, signal processing, and computer vision. However, I'm starting to become concerned that if I pursue a career in embedded systems, I'll spend time implementing other people's math and not do any of my own analysis. My question for you as people with good understanding of the opportunities for people with embedded software skills in industry, do jobs exist that involve both of these aspects. I'd really like a career where I can think about interesting mathy questions, but also enjoy implementing and testing code on real devices.

Absolutely. 100%. And if you have those skills, people will seek you out and you will find the jobs, but they're not going to be at places like Facebook. They're not going to be at giant companies. Not likely to be at places like facebook they're not going to be giant companies not likely to be they're going to be at medical device companies if you want to do serious signal processing stuff what i'm thinking about is like one of the founders comes with you comes to you with an

academic paper it says we want to we want to implement. And it's full of physics and math. And you're one of the few developers there. There's nobody there to help you translate that physics and math into code. Those kinds of opportunities are likely to happen in smaller companies. Yeah, I guess... They're going to hire PhDs for the other stuff, for the most giant companies. They're going to have whole research groups that are off in a corner in a dark room, and they'll hand you some MATLAB or some badly written C that you have to fix.

And that's not what TANI wants to be doing. Yeah, and I see where you're going with this, and I keep going back to, well, at HP Labs, I got to do all of that. But that was kind of a special situation there are big companies that will have you do a job and help you cross train yeah but i don't feel like those are there are also big companies that will tell you you can do that and then you're a cog for 10 years yeah um a lot of the startups i work with i do get the opportunity to do more controls and signal processing. And lately, even computer vision and machine learning. So I think absolutely yes.

If you can understand the algorithms, you can do mathy things, you will be able to do mathy things. But you may have to go to smaller companies for it. Because they can't hire two people. Yeah, that's kind of where I was headed. They might have one PhD who's like the kind of founder or the CTO kind of person. And then they need a team of engineers. And that person's not necessarily going to be able to spend a ton of time

doing implementation or even be capable of it. So they might just have a great idea and a paper, something that came out of their thesis or their university work. Now they're building a company around it, and they need somebody to implement it and be able to talk to them. That's the other thing is having engineers who are able to talk to the researchers and understand what's going on, that's a big deal. And if you get a job or two where you've done that well,

you'll become indispensable, I think. Yeah, and many of my favorite jobs have been a super smart PhD whose code looks about like what you don't want and who can talk to me. And because they can talk to me, I can write their code for them. And it's not like I'm not implementing my own algorithms because they're talking with me, not just demanding things. And then, I mean, sometimes that leads to being a co-author on a paper

because you point out something they didn't expect. And it's really a discussion. If you find people like that, follow them. They're great. The other kinds of jobs that you might find are things like the HP Labs kind of companies. Xerox, Parks, they'll be hard to get into maybe, but I'm trying to think, uh, even universities sometimes have, uh, research teams that, that hire people, right? Yeah. Um,

Slack, things like that. Um, how come you made fun of Facebook, but not Slack? Slack without a K. Oh, Stanford, Stanford linear accelerator. Yeah, yeah, yeah. Slack does not do any research except on how to consume more and more RAM. So, no, I think there are a lot of jobs out there, but it's going to be a little bit, you're going to

have to be picky and choosy, which coming straight out of school, you might find yourself accepting whatever you get first and then making sure you keep up your skills. Maybe through grad school. Yeah. I would say I don't necessarily want to encourage somebody to go to grad school because that's just mean and awful but um the your ability to your ability to

interface with the researchers and actually turn papers into code will be increased greatly by getting a master's degree and that's the other way to go about this if you enjoy the deep, mathy, technical algorithms, the theories. If you decide to go that path, if you decide to go the path of an academic or a more theoretical person, nobody on that path is going to tell you, no, you can't also play with hardware. The person in the lab who understands both the theory and can fix the hardware, that's going to be a pretty valuable person. But it's going to be in a lab. So it depends on which aspect you want to go, either as an engineer who has a little bit of extra or as an academic who also has a different bit of extra. But I think it's extra either way.

So good job. Keep going. Do you think we answered Danny's question? We talked a lot. That's all we really need. Okay, one more question-ish thing. So Lady M wrote in and says that she's really interested to build her own CubeSat or TubeSat from scratch. Wanted recommendations on resources, groups of like-minded people, competitions to take part of. Not part of a school. So what can non-students do to

explore more embedded design and real-time systems in space applications? I do not know. I didn't either. So I emailed Stuart McAndrew. That was a good choice. Stuart's a listener and we've talked a few times and I knew that he was working on a satellite himself. And so I decided, why am I trying to answer this question? I have no idea how to answer. And Stuart had some ideas.

First, Stuart suggested not tube sat. Tube sat? Well, there's cube sats and tube sats. Okay. Which just seems like a naming issue. Yeah, it's a little strange. And Stuart says not being a student makes it a lot harder. Yeah.

One of my suggestions there was, well, you can still learn a lot by mentoring students. Some high schools are doing satellites these days. Yeah, that's true. And you can have a lot to offer them, even if it's just encouragement and reading the manuals when they're done. Pocket Cube is a Pico satellite, a non-educational entity. If you actually want to try to get into space, the pocket cubes are cheaper than CubeSats, but still more expensive than the free ride educational CubeSats get.

So you can look at the pocket cubes. There are some public information forums about that for military and civil. Yeah. But the problem that Stuart had is that the question was too broad. It's, it's like asking, how do I get a job at embedded systems? Simplified answer is to learn stuff and do stuff.

But how do you get to the point where someone will pay you? And figuring out what to focus on, do you want to do fault-tolerant processing and FPGA? Machine learning for Earth observation, software-defined radio. Space is cool because it's hard and neat and awesome but it's still got most of the issues that terrestrial processing has too

You know what, I'd just make an undersea rover So Stuart's main advice was to figure out a specific goal. Yeah. And once you have that, then you might be better off. Yeah, because really, I want to build a computer that goes into space. It's pretty broad.

It is. But there are resources out there. I mean, CubeSat has a big following, and looking for stuff on that is helpful. I still say if you can find an educational facility to participate with, you're better off. Yeah. Well, that's it for the outline. All right, then. Let's see.

I didn't even write in thank you. Let's see. Thank you to Christopher for... Nothing. Everything. And for co-hosting and co-producing this show. I've been demoted to co-producer? I'm joking. No, I'm sorry. For hosting and producing this show.

You're executive producer. I'm producer, producer. I don't think I'm executive producer. I never okay at going. They get the big title. Yeah, but I don't have to do any of the work. Right, that's how it is. Oh, then that's fine. You do most of the work.

Thank you for listening. Thank you to our Patreon subscribers and Slack members, because that's been amusing. And thank you to the weather for finally clearing. It's finally summer here in Santa Cruz. And there are whales.

So, Winnie the Pooh? You've got the book. I've got the book. Is that the end of the story? Asked Christopher Robin. That's the end of that one. There are others. About Pooh and me?

And Piglet and Rabbit and all of you, don't you remember? I do remember. And then, when I try to remember, I forget. That day when Pooh and Piglet tried to catch the Heffalump. They didn't catch it, did they? No. Pooh couldn't because he hasn't any brain. Did I catch it? Well, that comes into the story. Christopher Robin nodded. I do remember, he said. Only Pooh doesn't very well. So that's why he likes having it told to him again. Because then it's a real story and not just a remembering. That's just how I feel, I said. Embedded is an independently produced radio show that focuses on the many aspects of engineering. It is a production of Logical Elegance, an embedded software consulting company in California.

If there are advertisements in the show, we did not put them there and do not receive money from them. At this time, our sponsors are Logical Elegance and listeners like you.