Embedded - 279: Top Pedant

Episode Date: February 22, 2019

Patrick Yeon (@patyeon) spoke with us about nonprofit spaceships then asked our opinions about embedded software. Pat is working for something something nonprofit space something something. To fill in some of the blanks, apply for a job on NonprofitSpaceship.org. Pat was previously on episode 153: Space Nerf Gun when we talked about cost-optimized satellites. We talked about several books: Turn the Ship Around! A True Story of Turning Followers into Leaders by L. David Marquet Managers Path: Leaders Navigating Growth and Change by Camille Fournier Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides Head First Design Patterns: A Brain-Friendly Guide by Eric Freeman, Elisabeth Robson, Bert Bates, Kathy Sierra Elecia’s command code is on github.  

Welcome. This is Embedded. I'm Alicia White, and I'm here with Christopher White and Patrick Eon. We're going to talk about nonprofits, cheap space hardware, testing, and whatever else comes up. Hi, Patrick. Thanks for joining us on the other side of the hill. Oh, thanks for having me. Came over 17 and got a little hailed out today, but it was a good day to leave the motorcycle at home. Yes. Other than living somewhere in the Bay Area, can you tell us about yourself? Yeah, so I'm an electrical engineer. Recently finished four years working with Planet Labs.

I was on about midway through that a couple years ago, where we were making small, you said cheap, but I was told to say cost-effective satellites and changing how people approached space at the time. And since leaving there, I've joined a different group, which is a more interesting take on how to do all this. So we are a nonprofit interested in affecting some space policy. And we have a very small spacecraft team that I'm building up to help us in those ends. And so we spoke to you, oh, it was 153, so 100 episodes ago and change. And that was Space Nerf Gun, where we talked about launching planets, little cost-effective satellite doves into flocks. Yeah. And now non-profit and now not just satellites. Right.

So a few friends got together and started a nonprofit. Um, and, uh, they have, they have a whole range of, um, kind of the big M mission that they want to achieve. And there's a whole bunch of, some policy people and some scientists and some academics all involved.

And a very small part of that is involving spacecraft to kind of prove out their ideas and set some precedents as the nonprofit wants to run things. we have more of an attitude of do first and then brag about having done it rather than make all your claims and deal with the distraction of everybody telling you you can't do it or how you should be doing it instead. There's some value in that. You don't usually think about nonprofits building things. You think of them as advocacy organizations, planetary society, and in this space where they're advocating for space exploration and planetary society and in this space where uh you know they're advocating for space exploration and and planetary exploration and education in general so i'm curious about the actually building hardware is it like in maybe this is without getting into too many specifics um is it like an open source thing where okay here's this kind of software and other people

can run with it well i'll point out that planetary society is involved with light sail okay and um that's true also with a with sample return missions and developing the technology for that and a big part of it for us is that as well is identifying technologies that are going to be required for the capital M mission and also operating as a demonstration that small organizations can do this kind of stuff. And it's not left to large national science teams, nor to say like mining companies to decide where humanity, how humanity is going to get into space and how we're going to operate once we're there and so are you going to develop some stuff in-house or grants or a mix of both a little bit of both okay in space policy i mean what is so far the policy for space is if you can get there how that there is no space policy i think there's a little more. I think that if a private venture went to Mars, they could do whatever they wanted.

But if the U.S. government supports something that goes to Mars, they can't contaminate it with human, I will say, crap, because that's the most honest answer. Depends on your launch, though. Launches have to be certified, so they could keep you from going if they knew. Right. I'm not sure, to be honest, once you get... I mean, I know that very small, very near-Earth orbit that planet was in. I know that fairly well. I'm not sure what kind of additional licensing you would need to go to other planets or to visit asteroids, say.

But I'm sure, like I suspect, governments are ready to tell you what you should and shouldn't do. And they can just tell you, no, you're not allowed to get on that rocket. Unless they launch from international waters on a boat or something. I'm thinking, you know, this is way more than three miles away from their land. Isn't space the definition of international waters you still have to get there yeah it's it's that's how they they regulate it is they they give licenses to get on a rocket and no license and you're not getting on the rocket okay um before we get too far into this because i have

so many questions um including light sail but uh what lightning round lightning round that's the thing we're going to do now um and i know you're familiar with it so go ahead chris you looked over and saw that i was ready just ready to go how big is space very favorite non-terrestrial object in the solar system? Right now, it would have to be Ultima Thule. That's the double pancake? It's the double pancake. That was the furthest thing we've just visited.

Okay. Zoomed past. And the Kuiper Belt, which turned out, right, it was a double pancake, not a snowman. What planet or moon would you visit if you could? I'd like to go to Europa. Yeah. See if we can go fishing. Yeah.

I've seen that movie. The fish are big. They're fishing for you. Spoilers. Do you think there will ever, not just in our lifetimes, but ever be FTL travel? The physicists tell me there won't. So I'm going to say no. Yeah, but have they always been right?

Hey, they've sometimes been right. Favorite hockey team? Montreal Canadiens. Plural of moose? Meese. That was so quick. What is your favorite irrational number? Oh, wow.

There's so many to pick from. There's probably an infinite number to pick from. By definition, yeah. Okay. All of them. All of them. All of them works. Back to non-profit spaceship, which is what'm calling it because um that's the website you sent

me to non non-profit spaceship.org which i thought maybe you were punking me i mean non-profit spaceship company that just sounds right yeah um when i do the initial pitch on this to people, I usually find myself talking for 10, 15 minutes about it. And then I kind of catch myself when I stop, like, am I sounding crazy, too crazy, not too crazy enough to pull this off? And what we are is a small nonprofit working to influence how humans settle and spread out into space. And that involves a bunch of advisors and a whole bunch of people kind of identifying the roadmap to get there. team looking to run a few lowercase missions using spacecraft developed in-house to help push along our uppercase organization mission. I can tell that you're leaving some things out. And I know that there isn't a lot you can tell us more about it because of reasons,

all the reasons that are typically given. Right. All the decisions that I don't get to make. But you are hiring. We are. So that small spacecraft team currently consists of two of us, and we're hoping for it to consist of 12 of us. So that's why the nonprofit spaceship website is up so that we can give you a paragraph about what we do and little descriptions of the jobs. So it's, it's everything that you expect out of this kind of crazy with small teams,

self-directed moving quickly, hard technical problems and come, come hang out in San Francisco. Right. And you do have to be in san francisco it is yes do you have personal feelings about getting humans off this rock i have i have mixed feelings to be honest i i can uh having lost data before I can definitely buy into the backup civilization idea. That's the idea that humans have to be somewhere else in case a giant comet comes and

takes this planet. That, and I mean, to be honest these days, in case humans come and take our own planet, but I also don't subscribe to the let's go terraform Mars because it's easier than fixing the Earth because we should really work on fixing the Earth. It's kind of like saying, let's rewrite this whole program instead of debugging it. Instead of fixing the one bug, yeah. What about the notion that humans are better at doing research on a planet? You mentioned Europa, than sending a probe. quick thinking and able to analyze a situation and make decisions, both make decisions in real

time, but also kind of contort ourselves to pull off things that a robot that had a very specific mission wouldn't be able to do. I think robotics and space have a definite position in exploration where you don't have to keep them fed and breathing. And you can send them a lot further for a lot cheaper because of that. And you can leave them on Mars for 14 years. And when they pass away, everybody's sad, but they don't all hate you. Right. This is opportunity we just, well, not we, but NASA just officially gave up on last week. 90-day mission.

Just keep remembering it was a 90-day mission that lasted 14 years. VX works. It was. It was. Moving on from space technology, because I don't want to get either of us in trouble and I want you to tell me all the details later so that I have them. I like secrets. No, don't tell me secrets. I never

remember what's what. You had questions for us and yeah, this is a quiz. That's not fair. That's not how this works. You were given the questions beforehand. You had a lot of time to prepare, Chris. You haven't even opened the file, have you?

My whole approach to this podcast is not preparing, as I think everyone can tell. So, okay. All right. All right. There was one about the correct way to do test-driven development. A bit about the correct way to do test-driven development? A bit about the correct way more. So I'm coming from an electrical engineering side and I dabble or role play as a firmware engineer at times. And yeah, Grenning's book, Test-Driven Development for Embedded C, I believe, really, really opened that up for me. And I've done okay doing what I think are unit

tests. But I've also been wondering, how do you, what do you test one step above that? Once you have all your unit tests passing, how do you prove that they all, the whole system works together, other than plugging the hardware in and hoping? And how do you test that ongoing as you make changes? I mean, you're asking about integration testing. And that is a of your unit tests. Because just as your small flash driver can have a mock and the mock can be used to test out your flash driver code,

whatever you're using on top of your flash driver, your logger code, can be used all the way through so that it has this it's using the same flash mock. And then on top of the logger code, there's your state machine. And so you can ideally test your whole system because what you're doing is writing a test for every piece of code you're writing. And the pieces of code you're writing depend upon each other. And so they depend upon the other tests. That's the theory, anyway.

Is that okay to use with my unit testing framework, or are the real, I'm doing air quotes here, real software engineers going to get all mad at me for mixing my... No, I don't think so. I mean, from a practical point of view, what I'm used to is people start out with good intentions of unit tests. And so as you start developing the low-level bits have unit tests, you know, you're small. You know, maybe you have a library that does a container linked list and things like that, and you build it up, and your drivers have unit tests. And so pieces that are small have unit tests. And then, like you said, when we get to the higher layers, things tend to break down, at least from a project management standpoint,

and people do less and less testing like that. And then it ends up going, what usually ends up happening is the QA team ends up coming up with their own test plan for the whole system. And that's more of a black box kind of testing. They don't, It's not in the code. It's scripted, maybe interacting with the manufacturing console or with the UI directly. But it's a series of scripts that tests the whole system from the outside. And then it says pass or fail, and they build their own things so that that's what usually ends up happening is you have some unit tests for the critical core things that people get worried about and then everything gets left to qa um what elise is saying is to take that unit test approach all the way up and that's that's what i'm seeing in app development more is yeah every every piece has a unit test even the mid layers and the upper layers uh and use the same frameworks primarily unless you're doing something like ui and that has a different one because it's because you need to try as it clicks yeah exactly swipe and spin and flip your phone and but you can write a unit test for a calman

filter algorithm yeah you have the inputs you have the outputs you have the inputs, you have the outputs, you have the test. Now your inputs in the field depend on sensors, which may be inexact. And your unit tests in the office may be generated by perfect sensors. Or maybe you have some that are generated by perfect sensors, and some that are generated on dirty data taken from the field and rerun. And your idea there is not, is it giving me the optimal answer? It's just, is it giving me an answer on this real data that's worse than the answer I got before? And so you're doing the unit test. It's just the same. I mean, Grenin would say every line of code needs a test. I don't go that far, but I'm willing to take that approach, at least in theory. To push

to try and get there. Yeah. Just stop when you run out of time. But there's no reason to think that a flash driver needs a unit test more than a logging system does. You could do it either way. Now, the difficulty here is when you're writing that low-level stuff, if you haven't architected your system quite right, you might

write all that low-level stuff with good APIs because everybody's accessing it. And as you get further up, things might get a little bit more muddled. So the tricky part about extending unit tests higher sometimes is that you aren't exposing apis the same way so it's harder to write a test for say a big piece of signal processing because maybe it's oriented tightly to plug into this part of your system and you haven't necessarily exposed things right because you didn't think about it that way um that that's a place i get in trouble sometimes it's like you write a bunch of code and like okay okay, now there's right. The unit. Oh, it can't see this. Right.

And at what point are you exposing things that you have no other business reason to expose other than testing, which I think I've gotten comfortable with, especially internal projects that, oh, this is invalid by some assumption of what should be private and public but you know what if it helps me have more faith in my work then i'm okay with it and there's tricks you can do too like when i've done some in c++ when you build the unit tests you pound to find private to public then suddenly the unit tests can see everything um i feel so uncomfortable all of a sudden it depends yeah it depends i'm not sure i'm comfortable with that either uh that that suggests that perhaps you haven't designed the interfaces correctly but and then when i'm working specifically on embedded systems and a lot of my i i found myself like writing low fidelityidelity mocks or emulators for different parts of the chip or peripherals on the chip or off-board sensors. And at what point am I also designing a poor emulator and having to test that so that I can test, I don't know?

Yes, that is the hardest part about test-driven development and embedded systems is the mocks. It's not just embedded systems. I had to write one last week where I'm accessing a website to get data. I can't do that in Unitest. Are we going to have and returned the data. So that happens all over because there's all kinds of things you can't easily emulate. Exactly. And writing your own emulator for everything gets a little silly. You can instead do things like I was saying before, where you take a bunch of data from the real-life system, and that's what you use.

You don't make it mocks all the way down. You just test with your inputs and your outputs. And so instead of making sure that your Kalman filter works with your accelerometer, which works with your accelerometer driver, which works with your spy driver, blah, blah, blah. Instead, you just say, okay, here is the algorithm. Here is the input. I want this to go to that. And if it works, good. And some point you you put it all together and you start testing it in with hardware in the loop and i don't i'm not a big fan of making emulators for everything because they get just as buggy as your code does and then your code depends on the bugs in your emulator which is weird i can see that and i can see a sense of a false sense of confidence if like oh it looks fine in the emulator

i mean so this is coming from the last big uh firmware project that i worked on was controlling a 25 foot wide satellite dish and i like i was very motivated to test this a lot in software because i assume that would have been very expensive had I tried to drive it through itself. I was very motivated to not do that. Try not to make the satellite dish go into the ground. Yeah. Or if you're working on vehicles, I'm very motivated by not having everything reboot as you're merging onto the freeway. That seems like maybe the wrong time. Well, and testing with Vue. A couple of times.

I told Chris I crashed the car. What I meant was the car software crashed. You need to disambiguate that. But even with driving, that's a good example because going out and taking driving integration tests is a pain. Oh, it's never going to be the same inputs. It's never going to be the same inputs, but it also is just very time consuming. What you want is to collect a bunch of data and then be able to rerun it at your desk. Ideally at, you know, 10x real life speeds.

But you don't want to build an emulator for a car, not every single piece. You wouldn't download a car, sorry. Yeah, and that depends on, again, designing good APIs. You can inject stuff precisely where you want to in your tests and separate things apart. Yeah, separation is the key key did that help at all i think this is it was a lot of words no it's yeah i'll re-listen again and i feel i feel like

it at least confirms i'm not doing anything you're not doing anything wrong i don't think i don't think there is a right there's a lot of people with opinions that are very strong, sometimes that I'm not sure are possible to implement fully. Where then it's all, you know, who is top pedant about what's actually a unit test and what's not and whether you've done it all wrong or, you know. You should think about your goals. Yeah. And my goals with unit tests tend to be different from other people's. Other people's might be we want to produce bug-free code from the beginning or very early um i tend not to think so much about that and more about the long-term health of a code base and in that case i like unit tests for preventing regressions

and for making sure that things don't rot or that people don't just break things in new ways. Right, and that has been super valuable, I've found, when I change something over in file A and then a unit test on file F starts failing. Exactly. This is, that shouldn't be happening, and yet here we are. One of your other questions, uh, dealt with practices to develop, to reduce bug count and have more faith in your work. I liked that question a

lot, of course. Um, and again, that's coming from as a, when I, where I am experimenting or learning to write code is on, uh on embedded systems, you know, actual hardware that at some point is probably going to connect to something that can physically hurt me. Whether that's wise or not is a whole other conversation. But I'd like to have some confidence that it won't hurt me or it won't just damage itself. And what are i've seen people talk about um assertions on your assumptions as you enter and exit every function or um range checking everywhere and that seems uh i mean it's a lot of work it is a lot of work um there are things that will help you with that. I don't think that's the place to go, though. I mean, sure, asserts, good.

Range checking, usually good. Those are all very small, little tactical things. Those are very small, tactical things. And what Chris said earlier was what made me go to the next question, which was you have to think about it from the start. You have to think about what you want. And so instead of adding assumptions and assertions, I think you should start adding planning documents.

I know that that comes out sounding so bad, but it's kind of like test-driven development in that test-driven development forces you to say, what should this not do in order for it to work? You know, how do I get it to pass my test? What is the minimum I need to do? But the software requirements document says this is what the system should do. And I've thought about how to make it all do it together.

I've thought about how to break these parts up so that I can test each one. It's not how do I bolt on safety and reduce bug counts. It's how do I not make the big bugs to start with. Not the big bugs to start with. Not the little bugs, the little bugs of I read 23 and I should have read 24 and did something wrong that way. Those are little bugs. It's the big bugs of how do I test it? How do I even know that these two things can be read at the same time? How do I make sure the timing in the system is likely to be functional? And that is start at the beginning and have a design and keep up with it. Make sure the design is testable.

Maybe that means writing another document, maybe not. And keep up with the design. You can't just design it once and then walk away and do unit tests you have to design it and then when your design breaks fix your design and keep going i suspect that wasn't what you wanted me to say though well that's that sounds like a good part of it too um it's interesting that as i uh in a parallel track i'm moving from electrical engineer to a title, which at least suggests that I'm supposed to manage people. And my questions get, well, write more documents and sounds like, uh, something that a manager

would be doing or. Not necessarily. Uh, yeah. That a manager would be talking to an engineer in the dorm. That's what you're talking about. Write a document that will describe everything instead of do the work. But I think the documentation part, following the FDA kind of guideline, I don't know if NASA or some other organization has a similar. The European Union.

Do they? I've certainly the FAA documents. Yeah. Yeah. And I'm sure NASA does too. That's, it might be a little too ambitious to hope that everybody who is now space is following follows those documents, but you know,

a requirements document that's got a specification that follows it that points back to the requirements document, and then a verification document that points back to the requirements and says you have a test for everyone. You know, it's kind of the basic structure. One thing I was thinking as you were talking, though, because you said safety and things that hurt you, and that you're an electrical engineer. At the risk of being a heretic to software people, I've worked on projects where they were safety critical, and the first version was completely software-driven, a real-time operating system. We were pulse-modulating a laser for short pulses and delivering a precise amount of energy to somebody's

face. And this was all done timing and software and all the safety checks were done in software. And it was kind of a nightmare. And the second version, we didn't do a lot of that in software. We moved to some dedicated hardware that had integrators and, you know, photo sensors and things that had a whole analog path for accumulating how much energy had been delivered, putting that through an FPGA with a small amount of logic. That talked to the software in a redundant way. We had like two comparators and they had to agree. And then the software could look at that but

the act of shutting the laser down if something was wrong was done by the hardware and the software was just like oh i got a signal that things are bad here's a log of the energy beforehand but its hands were out of it to a certain extent and it's much easier if you can get your safety systems to be simple like that in hardware, it's much easier to validate and trust that than software. Right. So was that chosen because it was not necessarily easier to design or develop the hardware, but it was having done that more obvious that it wasn't wrong? Yes. So how do i make less mixed in with a giant other software project where all kinds of combinatorial bugs could exist so you're and then what i was calling assumptions are more obvious and more constrained yeah and i guess if if we want to keep on talking around in circles

my question would be like what you know tactical practices can i have writing software to also and maybe we're just back where we already started i mean there's compartmentalization where you have not a physical separation, but maybe you architect your software so that some pieces are different processes that can't interact except through narrow pipes to other pieces. So you have the safety-critical stuff in one process and the UI somewhere else, and they talk, but a bug in the UI can't cause a bug in the ui can't cause a bug

in the safety systems they're they're separate software um through tiny pipes through tiny very checkable pipes and then you uh have things like okay you have a software watchdog where do you put it in the safety system because if the safety system is not running the rest of the thing is toast you don't put it in the ui thread because if the ui isn't running i mean maybe you put another one there but that's not where the hardware interlock put in safety mode watchdog goes well also it seems to me you would want to know that the safety system is being called to keep the watchdog going, as opposed to if you're skipping it in the UI code, but you're still running your watchdog there. I mean, your watchdog isn't doing what you think it is, right?

Exactly. Your watchdog should watch the most important thing, which often is the idle loop, but that's a separate story. And then, you know, if your platform has protection features like a memory protection unit or a full-fledged MMU, you can, you know, have greater separation between your code elements because they're in different address spaces and things like that. And you can go nuts. I mean, you can get an ARM R core, which I think they have the multiple cores that run redundantly, right?

Yeah. If you think something's going to go wrong with your hardware or you think there's going to be a bug in your software that you can't be fully confident, they both run, and if they give different answers, then you throw up your hands. But it's a hard question question because without knowing exactly the details of the kinds of things you're worried about uh that goes into what kind of architecture you choose and i bet like just the

um what is the safest thing to do is very context and hardware dependent like with your laser it was the safest thing was to turn it off but again if we're on if we're in a car on the freeway the safest thing is not to turn it off exactly yeah in fact when i came to that company the first version had a big emergency stop switch in the front for somebody to bash but they made it a software interrupt so we'd get a signal that somebody pushed the emergency stop. It would take us, you know, even with the X-Works, it would take us 20, 30 milliseconds to get around to it. Meantime, you know, we're still shooting somebody maybe with a CW laser if we screwed up the timing. So, yeah, the first thing, one of the first things I did there was you take that button, electrical engineer, and you put it across mains.

Just disconnect the power. Why are you being fancy? Don't trust the software. God. I have totally. We had so many bugs because it never was a, it never, I don't think it ever caused a problem, but we had to be so careful that we just threw emergency stop errors all the time because there might be some little power dipper like i think we saw that signal well okay we probably did so turn it off right i had similar ones on this big antenna driver where things started looking a little weird like oh yeah just stop stop stop and um well again part of what motivated me to have a lot more faith in

what was happening was i would get phone calls at, you know, 11 PM, like, Hey Patrick, the antenna stopped and it threw all the breakers. Like we need to know if it's a real problem. It's like, Oh, probably not. But I guess I'll, I guess I'll go get the computer and log in and see what we saw. That's 11 PM support calls are great motivation to make things yes have there been bugs you've seen often have you started to think wow you know every time i use a byte it goes wrong because i must not understand that a byte is eight bits instead of four that's a terrible example i suspect you know how but it's the actually like the first thing that comes to mind is not far from that and i mean i just i can't count i keep on that's what computers are for yeah but i look at the data sheet and it says the 14th byte is this

and then i count through and like i definitely write in the right value for that byte. And I spend all afternoon trying to figure out why my chip isn't working. And I'm like, yeah, of course not. Because the 13th byte is what I'm writing. Please tell me I'm not the only person who sits there with their finger in those data sheets. One, two, three, four, five, one, two, one, two. And of course, you're going to be wrong anyway, because they start them all at zero. Exactly.

But yeah, just honestly, like, what's the pebcac problem exists between keyboard and chair? Yeah. That's the one that gets me. Just can't count there. Is there other bugs that like a taxonomy of bugs I'm seeing myself make a lot? I mean, that's a good one to know. That's a, okay, I sometimes need to print out a one page for everything that I'm really going to have trouble with. Because then I have to use the piece of paper. And I mark on the piece of paper what I thought.

And then I can check it on the piece of paper. And then when I get to the code, I have the, oh, it's supposed to be 0xf, not 0x00f, whatever. I mean, it's supposed to be this. And I can't, I may still mistype it, but it won't be because I forgot it. And I feel like there's so many times I'm like, oh, was it the two bit or the four bit I was supposed to set? And unless I write it down, I get, yeah, can't count. And that's actually, when you're talking about writing down what you thought you were going to write, and then writing down what you actually wrote. This, this seems a little extreme to me, but I have heard people advocate for the first time

you write you run your new code should be in a debugger and you can sit there and say like well i thought i set this variable to 0xf did i and you just step through and check that's it seems like a lot of work but again so does spending all afternoon chasing down the wrong bug. Well, I mean, the truth is I never start with a debugger. But the second time I run my code, I start with a debugger. And James Grenning and TDD advocates would say, well, you never need to use your debugger if you're doing TDD correctly, which I'm incapable of doing. Yeah, if I knew exactly how everything was supposed to work when i got started i also wouldn't need tdd but here we are yeah and also uh thinking of where i find bugs

i i do the thing that you know we all know we shouldn't be doing, which is I start off by throwing a lot, well, some massive code together, compiling and not thinking to turn on certain warnings or errors. And then when you get a little bit later, okay, okay, this is a serious thing. I am now an adult interacting with adult code. And I am going to do what I tell everybody else to do and turn on all the warnings. Like, oh my gosh, I've been doing this to numbers? You poor integers. Dash W all, dash W error. And then you won't be able to compile.

Dash W extra? Well. Oh no? You can go too far. Yeah, I can't imagine not compiling with wall the great thing about the stuff I'm doing now is it screams at me while I edit

yeah the modern type type type oh you blah blah blah you've done this wrong I haven't finished the line yet yeah I had a java id that did that back when I was you know forced to do that the neat thing about it is you hit enter, and it tabs over, and you don't notice, and you do your next lines. And then a few minutes later, it gets around to checking your code.

Oh, you've got extra white space in all these lines. You put it there. So, yeah. By doing it through editor, huh? It's good stuff. You should use Vim. I've heard it's really good. Sorry. I'm not taking that bait i'm waiting for everybody to stop shaking their fist at the at the radio so you know okay um this the next question you had uh about commands

maybe i should let you set that one up. Yeah, again, when I'm making my own little hobby devices, eventually I want to be able to interact with it. And because it's always there these days, it's going to be over USB and some serial port. And I mean, I know how to read one character. And if I type an A at it, it'll do one thing, and then if I type X, it'll do another thing. But as you get more involved and you kind of want to maybe have a little more verbose commands, or you find you have a whole bunch of commands and a large switch statement, and then you want to pass values to some of them. And like, at what point am I writing like a whole compiler just for my command language? Does that make sense? Should I be doing that?

It makes so much sense. You should be doing that. Don't worry, it's not going to be a whole compiler. Okay. A very little compiler. Not even a compiler. So having glanced at your code, not in great depth,

you are sending one byte. Oh God, we're doing a live code review here? Have we ever done this before? And you then use that to go into a switch statement, which then you might read additional bytes. Sorry, what language is this in? C.

Okay. This is C. This is this in? C. Okay. This is C. This is running on STM32s because, again, why would you use anything else? They're cheap and they work. Yeah, so switching on the first byte to be kind of the command word and then knowing based on that byte

whether there are follow-on values. Okay, so I'm hoping people have a good enough picture of that knowing based on that bite whether there are follow-on values. Okay. So I'm hoping people have a good enough picture of that because there's so much more. There's so much more. Okay. First, I really like this question because we've talked about having more educational shows, and that was one of the reasons you were going to talk to us.

And one of the shows we were talking about having was about design patterns. Do you know what design patterns are? I've heard of of them and i'm aware there's a big book that yeah there's another one right there you can see it under the ios ones that's the bottom i like that one yeah that one's pretty good uh i mean it's doing what i assume these design patterns book all books always do and sitting on a desk or in a bookshelf of a software engineer i actually read that yes it's there for reference uh the trick with those though before we get too far is they're all object oriented they they lean heaven those kind of books lean heavily on object oriented stuff so if you're doing stuff in straight c you kind of

you kind of have to pick which ones make sense to translate into a non-object-oriented world. Yeah. I mean, I guess I just don't care that much about... Or it's hard to read that. Yes. It may be hard to read it if you're not doing object-oriented. But there is a design pattern from the Gang of Four who wrote the original design patterns book and design patterns are not intended to be tactical they're not intended to be assert on assumptions they are intended to give you a language so you can say i did this fairly big thing and i did it in the way most other people do it. And so having this language of ideas that you can just say, oh, I used the command pattern, not only tell somebody how to do it, it also gives you a resource

for how did everybody else do it? Is the command pattern an actual pattern that I should have? Yes, it is. Furiously taking notes here. So the command pattern in object-oriented world, you would design a class that had an execute function. And the execute function... And then you would design an interface, a UI or some other interface. In your case, it would be a serial stream. And the interface function would have a list of commands, and it would know how to say which one to call.

For C, that is usually a table, and it looks up which execute call to command using function pointers. That table, you know, it doesn't have to be one byte. You can actually type things at it. You can type adder, you can type remove, or you can type whatever you wanted to type. ADC to read the ADC. And then, so you have that, and you go through and you string compare until you find the one that matches. And then you call the function of interest. Now, there are two things that also need to be pointed out there.

After the function pointer, most people add another string called help. Then you can type help at the command line, and it will list all the commands you have implemented. Genius. So now we have this function pointer and it will call the execute function. The execute function doesn't read parameters. That should be part of the framework of the whole system in the object-oriented world that would be the framework of the invoker it would be the framework of the ui that you're calling and it would uh foresee you would have a function that says get uint16 and it would read whatever was in the serial buffer and it it would return an Uint 16. It would make sure that there was a Uint 16. It would make sure that it was valid.

It would do all of your checking. If you wanted to float and you got the letter W, it would send you an error. And so there's this whole idea of you have ways of checking your data that are consistent. You're not doing it on a per command basis. You have commands of you have ways of checking your data that are consistent. You're not doing it on a per command basis. You have commands and you have ways to get them. And it's a very steady, unique way of doing execute. And you don't use a switch statement. Now what you have is you go through this list, which is just a for loop, and then you have a bunch of functions, and you call whatever function you want. So yes, one of the reasons I really want to talk about design patterns on the show is there are all these other things that I feel like the software engineers know that we don't, that we use. We use this all the time. You wrote a command pattern

thing. You just did it without knowing, and if you had known, you would have had some easier ways to solve some of the other problems you came up with, like how to get the next argument. And so imagine there are 20 more things we already do that we could, if we could talk about them, if we could use the same language that the cs people do then maybe we could come on maybe everybody but embedded developers do okay okay everybody but embedded they're not cs people okay yes everybody else that everybody else except the electrical engineers use um and then we could say i implemented a command pattern and you wouldn't know what that meant and you might say well how did you handle the end of line problem or the white space problem because those might still be problems but the list of potential bugs goes down because now I've I've said that I've said the magic. So probably I have solved the problem of parameters.

And I feel like, you know, if you were to come to me and say, I implemented the command pattern, it at least saves you time in that when I go like, well, what's the command pattern? You're like, yeah, there's a book. Go read it. I'm going for lunch. As Chris pointed out, we don't really have a book that's really great about that. I mean, the subtitle of my book is Design Patterns for Embedded Systems. And you talk about command. And I do talk about command.

Yeah. But we don't have a book that isn't object-oriented. And there's so much we do that doesn't appear object-oriented, but still is using these patterns. I was going to go into some details about how I've done command-line parsing, but that's not necessary. Because you talked about validating parameters and stuff, and that's a step beyond what I've done in the past,

which is just to use var arcs. Oh, yeah. You know, I used to, I used get ops recently. Yeah. is just to use var args. Oh, yeah, you know, I used getops recently. That was pretty cool, except that... Well, that's for unix command. The person who pulled it off a unix command didn't realize we'd have to rerun it each time, and so... Did you use

gen getops? Oh, I'm getting way off. Look up gen getops. It's really cool. Anyway, but... I had a point. I had a point. But I forgot it. Yeah there's there's built-in ways in c to get variable numbers of arguments passed into a function so you can you can just dump them in there and say okay i'm in my execute for this i know i expect five arguments so you can say how many arguments are there and it says six and you go oh oh, that's an error. And then you can, you end up, you might end up with code that's validation checking,

that's replicated in the way she was suggesting of having a separate argument validator makes more sense. But I haven't done that. But if you look for command line parsers, there are a number of libraries out there if you just want to steal one. The problem with them is sometimes they have a lot of features that might not fit in your platform. Like one I tried to import a long, long time ago to a small platform had like history, which took up a lot of memory. So you have to turn stuff like that off. Right. And also maybe not so important on your...

Right. And also maybe not so important on your... Right. But if your job is to make spaceships, maybe you don't want to spend a ton of time making a command line parser is all I'm saying. If you can just grab one. Because there's way more fun stuff to do. But if you're trying to educate yourself at the same time, then that's perfectly cool.

And as long as we're on this, actually, that's one of the few pieces of code I have put up for total reusability. I wrote a command line parser for myself instead of for a client because I got sick of rewriting them. For every client. For every client. So I have one in GitHub. I'll post the link. But that's what I mean when I say the command pattern. That's what I mean.

God, I just want to go off on patterns again because I keep seeing people solving the same problem over and over again in different new buggy ways. I know you're excited about design patterns. I have been since 1998. I'm less excited. Tell me about the MVVCVCC. So there are design patterns.

They're the ones in that book. People haven't stopped there. No, they keep adding them. They keep making new ones. And sometimes people make new ones like every week. And they get more and more complicated and more difficult to explain. But they're like new programming languages. They become the new hot thing and everybody wants to use them and it gets and they may be good but as things get more sophisticated it gets harder to evaluate whether they're good or not so design patterns are good but there's a dark evil side to them yes you can take almost anything too far that's all i just

needed a rant that's fine did we answer that question? I think Patrick heard. Download Elysius Parser and never think about this again. I mean, that's a very satisfying answer to a lot of questions. Here's somebody else's solution and, you know, go for lunch. There are a lot of times that even if you can't use the solution because it's not licensed the way you want, reading other solutions is a good way to identify likely bugs and a good way to identify things you didn't think about when you first started thinking about it. look, they're handling spaces as part of the command, and they use slashes to indicate between them. I wonder if I should make mine variable or fix it.

Oh, they're checksumming that command before they try and run it, and like, oh, that makes sense. Maybe stuff could, wow, that's a thing I should do, yeah. Yeah, yeah. Well, I'd encourage you to look at it, oh, that makes sense. Maybe stuff could, wow, that's a thing I should do. Yeah. Yeah. Yeah. Well, I'd encourage you to look at it too, because the kind of thing that the command pattern does, table-driven code, you can use in all kinds of places, like state machine. Anywhere you kind of want to get away from. Here's a long switch statement. Or an if-then-else that's 100 pages long to something that's really tractable that could be imported from an Excel spreadsheet or some other markup. That's a good sub-pattern to kind of use as a table-driven thing.

Yeah. So that's another thing that I like about the sound of this is right now, the way I've written it, I have one chunk of code running on my microcontroller. And then I reimplement what all the commands are on some like Python host side. And I know exactly what happens when those don't line up. And I know exactly what happens when you're typing ADC into your... Hey, Patrick, what version of the script do I need for version 2.3 of the firmware? Yeah, no, that's like purple.pink. That's the one. Yeah.

What did I post recently about my IMU being compatible with the latest Marshmallow release? I was just... Yes, it was in a data sheet. It was in a data sheet. And I'm like, really? Marshmallow? That's not something I expected to see there. Okay, I think we have beaten this one into the ground.

Although if you have other questions, I can, you know, just pop design patterns as the solution. I'm willing. I have other opinions. Do you have other questions you want to ask so as we mentioned on the top i'm moving into a bit more of a leadership uh some kind of manager-like position um and i just how do i how do i not make that horrible for the people working with me? I've seen good and bad and sometimes worked for both good and bad. And I just, I really don't want to screw it up.

What did you like about the people who were good? I definitely felt like my good managers had my back. And I felt like they made less work for me as opposed to creating more work. I think that's a key thing is people say protecting people, but I think that's the wrong word. Sort of filtering. Filtering and pushing back upward the kinds of things that your team is asked to do. That's important while also being transparent about what's happening. Because I see a lot of times some managers are like, well, I'm protecting you guys from all this stuff. I'm like, well, some of that stuff I want to know because if you're gone,

I want to know what's coming when the next manager might not be so good at protecting me. Or maybe the direction of the company is slightly changing, but you're busy protecting me and keeping my head down. So it's a tough balance, and I don't have a good suggestion for that. But there are a lot of engineers who do want to be kind of plugged into, hey, I want to know what's going on in every aspect of the company. On the other hand, I don't want your manager to be telling me what to do every day. There's some element of oil in the water, making the whole thing less turbulent for the engineer and keeping them on track.

You didn't mention that they made you feel valued or that they made you feel like realize they're doing. And I could totally believe that a good manager was an advocate for me. And that's why somebody else came over and made me feel valued and said, thank you. And I see that now that you bring it up. Part of where I was going is that there's going to be a lot of things with management that you don't expect because people who have done well at it, did it quietly and people who didn't do it, you didn't realize why it wasn't as nice. So even emulating people that you respect and that you liked sometimes isn't enough.

There's also the problem that Chris likes more transparency. I tend to just want people to shove assignments under the door and leave me alone. No, I want that too. Just transparently. Yes. Every engineer is different. Every single one wants something else. And salary is only part of it.

Sometimes people want to feel like they're doing something really useful, which for a nonprofit spaceship, that's kind of cool. I hope so. People sometimes want to feel like they can drink with their managers. I don't really want to be buddies with my manager. I want them, I mean, lunch is fine, but I don't want to, you know, hiking buddy. It's really hard to figure out what motivates people. And if you can figure it out, they will follow you. They will follow you beyond where they might otherwise, because they feel like you care about them. And that's the hardest part. I mean, you have all

these things you need to do, and then you're going to have to care about people in their own specific ways, not just value them for their technological accomplishments. Although there are people who just want that. So it's management is hard for that reason. There's a book that I liked a lot, The Manager's Path by Camille Fournier. It was a book not just for a manager. It was a book I would recommend to new college grads because it told you the unwritten rules of the management pact. Like, what is a one-on-one really for? What should you do to make a one-on-one better as an engineer?

And it went through, okay, engineer, junior engineer, senior engineer. At what point do you start mentoring interns? And what do you do when you're told to mentor an intern? What does that mean? And then going into tech lead and management. And then she went on to middle management and CTO. But you can stop wherever you want. It just gives you an insight into what the person above you and the person

below you expect you to do. And so I liked it a lot. It was, it was pretty casually written. I mean, it didn't feel like it was a homework assignment. So I recommend that a lot. She had a lot of good ideas about the common problems that most managers have. It was kind of like design patterns for management i also i read a little while ago um turn the ship around which was about uh it was a management book but it's happening in the u.s navy and written from the, uh, the commanding officer of one submarine. And he describes how every chapter he starts with here was a problem. Here is how I obviously tried to solve the problem

and then it all backfired. And I'm, I mean, he ends up solving lots of problems, spoiler alert, but it kind of, it seems, I don't want to do all those backfires. And it seems a lot dealing with people and complex organizations that if you just do the obvious thing that you think is just going to fix everyone, it does the exact opposite. That sounds just like my code. Can we unit test our engineers? I think that's what interviews are supposed to be for. Chris, you were a manager for longer than I was. Although you had some engineers who just worked. Mm-hmm. Yeah, but they weren't, they, you know, there were issues.

There were issues. You know, you always think I have to solve these, I'm going to be a manager and have to solve these technical problems. But there's a lot of people problems, especially when perhaps one of your engineers doesn't like some other manager's engineer and things like that. Perhaps one of your engineers is extremely irreverent and talks back to your direct superior and things like that. That's the kind of stuff that there's not really a book for.

Actually, she identified some of those people. That's the kind of stuff that is right in really a book for. Actually, she identified some of those people. That's the kind of stuff that is right in that book that Alicia is mentioning. Those were actually the harder problems I had to deal with the first time I was a manager. The technical stuff, everybody on my team was okay. Most of the people on my team were self-directed and produced well, and so that was less difficult. And I was a technical manager, so I was setting technical direction. Yeah, the people stuff was more of a challenge.

And the second time wasn't for quite as long. It was a smaller team and it was a very small startup. And the problems I had there were less about people below me and more about the CEO and upper management issues. And that was more of a, how, how do I be a good manager to my team when I have major problems with everybody above me? And that little painting sounds pretty common in startups. As a, you know, having almost only done startups myself and kind of ending up in a startup-like situation again. I don't want to say it's always that. Like, it can definitely be fun too. I mean, if it weren't, I would stop.

But I'm also, I'm hoping that building a small team with a relatively small piece of the organization to work in and not importing a whole bunch of culture and history maybe maybe i'm a little too hopeful but maybe i'm doing easy mode right now i don't think so i think that that's kind of the ideal situation and what happened to me was i thought i was doing that and the CEO didn't exist for a year. And then he, he was a founder and he showed up and started laying down the law. And it was kind of a bait and switch. It's like, like you said, it was that kind of organization you're talking about where it's like, okay, this is great. We're autonomous. You know, we're doing,

it's a small group, everybody's happy. And then he decided to be more hands-on and the company changed so that's not really anything you can control but like you said if the situation is what you're talking about then that's great because you do have an opportunity to keep things separate but also define your own culture and define your own culture is maybe easy mode but it's certainly preferable to trying to drop into something and adapt. But hiring is so hard. Oh, absolutely. Well, like I said, my role is electrical engineer. And then when I joined, they told me, well, your title says lead, so go find some more people to lead.

And right now, I'm an engineer who's role playing as a recruiter because that's what we need to do. Yeah. I know you didn't want to talk about salaries, but I feel like we should reassure people that the company you're working for is funded. So it's not like people are expected to work nonprofit-free. That's right. Nonprofit is the structure of the organization in that we don't have almost every startup i've worked at was a non-profit that's a different story we are non-profit by design um it is donation based uh we're you know it's it's hard

describing um kind of what what well when i was at Planet First and an attitude we've adopted here of agile aerospace, which is much more risk tolerant than traditional aerospace. mean we're just going to be idiots with everything especially things that impact our people like funding and making sure people can make enough money to be comfortable the idea is like you're comfortable with small short-term risks on the technology side so that you don't it tends to reduce the risk of the whole project uh failing and yeah there's you know i guess if we're looking at money there's um a lot of smaller risks that any one person will donate or anything like that but we don't think it's a large-scale risk that the organization as a whole can't be funded does that help i mean that sounds more of a funding plan than many startups I've worked with. So, yeah, it certainly doesn't sound any riskier than 90BI. We're not at the whims of investors or markets because we've seen it all fall apart. And then all of a sudden somebody was very promising, has no money.

We're front-loading, having some money. So we know we have the money to follow through on little m missions before we start them and not just hoping that somebody is willing to buy something later and also you know i've i man i have so many so many stock options and they are worth so few dollars and i was promised they would be worth so many dollars but we can't do that so we're not like like we're at least being very honest about this is you know when we're talking about salaries like this is the money that's what you're going to make out of this and if you're working at a startup you do tend to get a lot of options in their monopoly money yeah You hope that the lottery tickets come home and they make some money.

And sometimes they do. Sometimes you get really lucky and more often not. Sadly. Well, I suspect we could talk for much longer, but I think it is time to go out and play. I'm okay by that. It looks like the sun is out and. And there's a beach. There's a beach here.

So Patrick, do you have any thoughts you'd like to leave us with? I think I'm going to give you the same one I did about a hundred episodes ago, which was advice given to me and don't be afraid to make mistakes. Our guest has been Patrick Yeun, lead EE working with a nonprofit on space things. You can check out their current openings at nonprofitspaceship.org.

Thank you for being with us, Patrick. Thank you. Thank you to Christopher for producing and co-hosting. And of course, thank you for listening. You can always contact us at show at embedded.fm or hit the contact link on embedded.fm. And now a quote to leave you with from Chris Hadfield, an astronaut from Canada. That seemed thematically appropriate. Look at who you want to be and start sculpting yourself into that person. You may not get exactly where you thought you'd be, but you will be doing things that suit you in a profession you believe in.

Don't let life randomly kick you into the adult you don't want to become. Embedded is an independently produced radio show you don't want to become. put them there and do not receive money from them. At this time, our sponsors are Logical Elegance and listeners like you.