Embedded - 245: Tell Me How People Hurt You

Episode Date: May 10, 2018

Stephen Kraig (@Macro_Ninjaneer) and Parker Dillmann (@LnghrnEngineer), of Macrofab (@MacroFab) joined us to chat about getting hardware and software to work together. Stephen and Parker are also hosts of the Macrofab podcast. We compared out-the-ordinary podcast guests. For MacroFab episode 112 it was their conversation with a patent lawyer. For Embedded episode 150 it was our conversation with a tax accountant. Schematics for the Apollo Guidance Computer (and their Kicad replica on github).

Welcome to Embedded. I'm Alacia White alongside Christopher White. Our guests slash co-hosts are Stephen Craig and Parker Dillman of Macrofab and hosts of the Macrofab podcast. Hey everyone. Crossover. Sorry. That's cool. So yeah, I'm Parker. And I'm Stephen. And we're from the

Macrofab Engineering Podcast. And I'm Chris from Embedded.fm Podcast. And I'm Elysia from Embedded.fm Podcast. And Logical Elegance and all of the other insane things i get into this is going well so far oh yeah okay we made it past the intro

okay let's let's do this oh can you tell us about yourselves and then we'll like share and all of that all right um yeah i'm parker doman i'm an electrical engineer um born and raised in texas um started our co-founder of macrofab um it's been my life for what the last four and a half years now um do electrical you know manufacturing for small os specializing in doing prototypes and small volume runs, stuff like that. I like Jeeps. I like hunting, camping, fishing, taking things apart. So that's probably what got me into all this. And I'm Stephen Craig. I'm also a native Texan for the majority of my life.

Not originally, but the majority. How can you be partially a native Texan? Because I have given up my Oklahoma residence. That is no longer. I'm officially a Texan. So I am a general purpose engineer at macro fab uh i have been at macro fab for two and a half three years something something like that yeah uh so i am a hacker and a hardware engineer i prefer analog audio electronics do a lot of work in that yeah we're kind of i i kind

of do more of the digital stuff and he does more of the analog stuff so we complement each other quite well on projects you look lovely today steven all right uh well i'm alicia white a native californian used to live in Southern California. Now I live in Northern California. Middle California. Middle. Software by training. Software and general engineer by training. And went to HP when I first got out of school, learned about big companies,

and just kept falling in love with ever smaller companies until finally I gave up and founded my own. And now we do embedded software consulting. I do embedded software consulting. Someone took a full-time job. So it went from like a million people to like two, right? And now it's at one. I've been abandoned. Oh, no.

You've reached full transcendence now. Yeah, I'm Chris, as we've already mentioned several times. I'm a software engineer as well, and started out also at a big company at Cisco Systems doing networking stuff, and then went to a startup doing more networking stuff, and then a succession of startups after that doing embedded systems things and medical devices consumer products all kinds of things i do not have electrical engineering training of any kind except by osmosis but i like playing music and the beach yes our beaches are a lot different than yours out there ours are a lot more brown

and kind of nasty so i'm excited about uh this podcast because we kind of have like both worlds coming together here we have the hardware and the software world and we kind of i guess we're going to take a peek into the minds of both, right? Yeah, that was kind of my goal. So we could find out what software and hardware engineers... Let's find out what's wrong with the other side. I was going to say want from each other, but we can go with what they hate about each other instead. That works too. Ten things I hate about you uh okay so do you want to do that or do you want to tell us more about your podcast first i mean sure we can i mean so the the macfab

engineering podcast actually was created just so we could we had a blog on our on our website macfab.com and um the problem with blogs is you have to make lots of content, a lot of, like, over and over regularly so that you have people coming to your blog a lot. And so I was writing articles at the time. This is before Stephen even came on. I was about to say, because I was writing articles, too. Yeah, but at the very beginning, it was just me writing articles.

And I could get, like, an article out every, but at the very beginning, it was just me writing articles. And I could get like an article out every like three months. So it was really slow. And then, well, because at the time there was like, yeah, well, at the time we had like six people here at Macrofab. And so like I was running the assembly line. I was doing like 80 different things. So writing an article was so far back on the back burner. And so we're like, how can we make more content regularly and make it easy? And that was kind of how the podcast came about. Steven came on board and he's like, yeah, podcast sounds fun. And we put together

five in my kitchen and published those and people seem to like it. And so we went to a studio and started recording and now we have our own equipment. Um, the big thing I like to, I, I try to hammer home with our podcast is it's not an advertisement. Um,

I don't like promoting Mac fab on the website, on the, on the, uhab on the podcast. And I like to talk about engineering and our projects and cool things that we see every week. So, yeah. Yeah, and you just kind of get our perspective on either what we're doing or what someone, one of our guests is doing. It's just a bunch of fun, you know, mainly it's hardware stuff, but it kind of covers a lot of other things at the same time.

But it's just kind of, you know, a fun thing that we get to do every week. Yeah. Yeah. And you have guests, but you also talk about news and what's current and all that. We usually avoid news and focus on guests uh do you have any favorite topics you like to hit uh how iot is that seems to be a recurring topic yeah that's there's been plenty of those for sure uh and and if you if you look back uh there would there's kind of two ways to describe uh one way for each one of us, it would be Parker equals Jeep and Steven equals synthesizer.

That too. That's a reoccurring theme. Both of those are reoccurring topics for us because we both do a lot of work in those. And it'll be something where if you listen from the beginning, you can hear Parker's jeep evolve throughout all of the it's almost sentient now yeah yeah yeah and and a lot of it is you know he's designing some kind of electronics or whatever crazy cruise control crap is going on in there yep you need to combine the two some sort of jeep synthesizer oh that'd be great but well okay okay, that's one of the biggest problems. I'll say that this is a problem with our podcast is we have gobs of projects that we do. And we talk about that on a regular basis. So thank you, but no thank you for giving us another project to do. I went through the list of Christopher's project on one show, and it was like 25 things long and made had and made him give him updates give updates on all of the projects and it was so ridiculous yeah that's now they're 30 and they're also in the same

status they were before uh i think if if that happened to me i'd have to go see a therapist well we haven't we haven't finished the project that we talked about on the very first podcast so that's still a box of parts it's tough because you do want to talk about interesting stuff but how do you do interesting stuff every week i mean realistically we have jobs we do technical things we can't talk about and so for our hobbies we're going to do electronics, and then we're going to make a podcast about them? Actually, that's kind of how it works. We usually alternate which one's project is the lead at the beginning of the podcast. And so we just alternate.

So basically, you get two weeks to kind of get some progress on a project going. Yeah, and you're scrambling the night before the podcast. Basically. Is this why you started having guests a lot uh not really it's usually guests are just to bring in some outside skill set that we don't really have well and at the same time i think as our listener base has grown, so has the desire for guests and people asking us. Well, yeah, people getting bored. Yeah, they don't want to keep hearing about Jeeps and synthesizers. They want to hear about something else.

But no, we just have more opportunities for guests, so it works out. Yeah. And it's fun for the host to talk to guests. I like that sometimes I can ask somebody I want to ask technical questions of, and I can say, hey, be on the show, and then I can ask them all my personal technical questions and not have to go through support forms. Your own personal FAE.

Right. We actually sort of had that the other week when we had a patent lawyer on, and we discussed it. And if you listen to that podcast, you get basically your first hour of legal counsel for free in a way, you know, if you really read between the lines. That's a good one. We had our accountant on once to talk about incorporating businesses and taxes.

And it was totally outside the scope of what we usually talk about, but it was fun. And I think a lot of people listened to it. That's great. Okay, well, shall we get to the actual how to make stuff? Let's do it. How to make software and hardware engineers work better together. Wow, that really doesn't flow well, does it? So what are the things you hate about us?

You know, what's actually funny is I've actually only worked on two projects in my life that had separate software and hardware engineers. Was Macrofab one of them? No. It was the previous company I worked with which was dynamic perception with church which is our co-founder here at macfab he was the other founder there at dynamic perception and he was the person who was writing all the code and i was designing the hardware um so this is it's this is going to be very interesting podcast because i haven't really worked like this before like with these two separate like i usually for my personal projects i write all my firmware um now i write it poorly but um i try well and i think a lot of your projects uh they're large

but they're not of the scale that requires a team oh that's true too well no no the uh pinball controller has a dev team now that's true yeah yeah so maybe i'll learn something how to manage that because i have no idea what i'm doing yeah you'll learn why they hate us i guess or yeah so i've worked on uh some teams before um where i've actually had uh technically the the product line i was working on was owned by me like my name was on it but i had a dedicated firmware engineer and a dedicated software engineer who in all honesty they were you know we all own the project equally and so the firmware guy did all the code for my micro that was on my my boards And then the person doing the software, she wrote all the code for the test programs and things like that.

So I have a little bit of experience of working hand-in-hand every day with software guys. That's funny. I don't work as closely with hardware guys as I used to because I am doing more startup work and they want breadboards so then they get prototypes so they can get venture capital. But I end up buying my boards off of Tindy or Adafruit or Sparkfront or AliExpress and just slapping them together and hoping that nothing really goes

wrong with that plan. But I used to, you know, I used to sit next to my double E. I used to share an office with my double E. And we would talk every day. It's weird to have more separation than there used to be. Well, as the companies get larger, the separation gets further and further. Yeah, you get the separate divisions. Different departments, and then you have meetings that occasionally you'll cross paths. Well, as the companies get larger, the separation gets further and further. Yeah, you get the separate divisions.

And then you have meetings that occasionally you'll cross paths and the occasional schematic review. Usually there isn't a reciprocal thing of any kind of firmware review by hardware people. Which is a little unfortunate sometimes. Yeah, and then lots of miscommunication and anger. So I think it's the separation that causes separation that causes problems a lot of times because people will make decisions that they think are best and they won't even realize that they have some implication yeah yeah how that affects other other aspects of the project well yeah and and and to be honest in in in all reality i see

kind of the hardware firmware side maybe there's a little bit of distinction when you come to software but the hardware firmware side those guys are are in bed you know all the time i mean those guys are linked together almost 24 7 with what they have to do because they because if any one of of those people make a change to a product it affects everyone else and so you really have to you know you have to have real strong communication with your software people uh and your firmware people uh or you will get you know you will result in anger i guess the way you put it well i don't know i mean it depends on your definition of firmware. It's kind of loose.

We don't want to get started on that. We've had like full day arguments on where firmware starts and where firmware ends here at MacroFab. Oh, I don't think there is an answer to that. I mean, when you say firmware, some people will say, oh, no, that's the microcode. If you're actually writing in C, that's not real firmware. And other people will say— Who are those people? I've worked with one of them.

Actually, one of them argued with me. One of the people you worked with who wrote microcode. And then there are people who are like, well, if it's not on the web— That's hardcore gatekeeping. Yeah. You must write an object or assembly code to be firmware. So, I mean, firmware is between hardware and software, and whether the software is on the device or the software is in the cloud,

I don't think there's a solid line. There isn't a solid line in the stuff I do every day. No. I mean, people would define what I do in the morning is software and maybe the afternoon is firmware uh and it's all one stack you know going kind of morphing from one to the other so it's yeah it's a tough thing to define you were just complaining about you were having arguments with both the hardware engineers and the design team because there was no industrial design team there's no way you could solve both of their problems at the same time.

Right. So that's firmware for sure. Yes. Yeah, we should just argue about this. Actually, how about this? What makes an embedded system embedded? Oh, God, not again. No, no, it's pretty easy. An embedded system is purpose-built

for its application. And what that usually means is it's resource constrained. Now, is a phone an embedded system? Well, to the person who has to program the operating system or figure out its sleep states, absolutely, because they are totally resource constrained. To the person who's writing Candy Crush? No, it's a computer. And so you can have different perspectives for the same device, but it's whether or not you are worried about your resources and how you are constrained within them to most efficiently serve the purpose of the device. So it's a sliding scale in a way. It depends on what you use it for or what part of it you're working on.

Yeah. But of course, there are things like Fitbit or microwaves or even cars that you have to say, those are definitely embedded because nobody works on them who isn't aware of their resource constraints. Really? Sorry. Fitbit, yeah. definitely embedded because nobody works on them who isn't aware of their resource constraints really that's a really good definition javascript apps so i don't know but let me let me throw a monkey wrench in real quick what about a raspberry pi is that an embedded system or not like if you write if you write a python program that runs on it wait what if you write a python program that like spins a servo using some of the pins did you just come change a computer into an embedded system because i think yes and i think that that's the purpose-built

single use thing i mean well i okay how about this example i worked on medical imaging scanners that the main core was a windows computer is that an embedded system it did one thing yes definitely yeah we have a reflow oven that has windows xp on it so i mean it does one thing reflow boards yeah the uh the self checkouts at at Home Depot all run PIC microcontrollers. They are embedded systems. They do one thing. And so the Raspberry Pi, I go back and forth because that is such a computer. It is such a bigger computer than I had for all of the first 10 computers I had.

So how is that not a computer? But then once you put it in a robot and all it's doing is controlling the robot, then how is it a computer anymore? It's a controller. So I think it can be unuseful to discuss this too much. Yeah, because you can get lost. We jump right to the meta side of the Actually discuss this. Yeah. Because you can get lost. We jump right to like the meta side

of the differences between hardware and software. But I think, you know, something that interacts with the real world, something that has a single purpose, that's probably a pretty good... You pass butter. Yeah. Yeah, you pass butter, exactly.

Okay, but we know what hardware is. Do we? Even though hardware isn't as clear-cut as it used to be. We're getting full on this. FPGA seems like software to me. Flat Flix PCBs, they're not real hard. That's true. How do you feel about those?

I mean, I see a lot of hardware engineers using them, and I'm like, you know you can't solder to them, right? And then they come back, and they're like, oh, it's totally fine. And then after five of them have burned on their soldering iron, they're all, oh, I wish I'd used a real board. Oh, we solder flat flex all the time here. It's not a problem. Yeah, and there's purpose-built soldering irons. What do they call them?

Hot bars. They call them hot bars for purpose-built for flat flex. They're just really, really wide soldering tips. On an arbor press, basically. But they're cooler too, aren't they? Yeah, well, it depends. Because you're still trying to solder lead-free, so you still need the hot temperature. Yeah, you still got to get hot enough.

So it's actually, sometimes it's even hotter, so it gets a higher impulse with less heat soakage. Okay. That makes sense. I still don't love flex because I definitely cannot solder on them. And I have watched my hardware engineers flame their flex ports. Their expensive flex connectors. And then you're like, I shouldn't laugh. I shouldn't laugh. I shouldn't laugh.

I shouldn't laugh. I'll just go to the bathroom. Oh, so go back to the, like, we were talking about, Chris was talking about what hardware is. So he brought up the example FBGAs, which is very interesting, because what is, like, VHDL and Verilog code, then? It's a physical definition of metal connections inside of a semiconductor device. So, in a sense, it is code.

It's code, but it represents a hardware structure. Not directly. It's sort of like a picture, in a way. Hmm. in a way. I've always thought about it as a logical definition of how things are clocked and what to do when certain clocks happen. It seems more like C code to me, except all at once. Yeah, it's a lot like C code. The thing is, it's C code that kind of likes... We're talking about verilog

it's kind of like c code that compiles into a hardware definition of what's going on right that's what i was meaning by a picture like it actually physically changes something in the real world you know i guess you could argue that nah i'm not going to go there now we're getting way too meta i was about to argue about code changing things in memory but we won't go down that route yeah but nobody looks at memory but you could look at a schematic that an fpga represents that's right you could actually write a schematic of what you ask the fpga oh whole gate logic you could if you really wanted to you really wanted to i mean people do yeah i mean that would be horrible that would be yeah but somebody out there probably does do that.

Well, in school, the first time you program at FPGA, you do it with gate logic. You draw out all the gates and connect it together. And then once you learn VHDL or Verilog, you're like, why did they make us do that? I'm never doing that again. Exactly. Right, yeah.

Okay, let's see. We have actual questions again. Exactly. Right. Yeah. Okay. Let's see. We have actual questions here. Oh, right. There was this one. This one is a big baffling question for me. Do you like pics? Like, really?

Like, you like pics? What did they do to you? That's probably to Steven. Yeah, that probably. Okay, so I'll give i'll give just a short story on it pics are i i do like them and and one of the reasons why i like them or or a chunk of the reason why i like them probably has to do with nostalgia so uh at my school i studied mainly uh semiconductor physics and analog electronics. I did very little digital electronics at my school,

and that was by choice. It just didn't interest me, and it wasn't big on my to-do list. But after I got out of school, I realized, well, I have to learn this sometime. And so just not knowing so much about it, I just decided to go with PIC. And I taught myself everything microcontrollers based on PIC architecture. And I literally just got a data sheet and read the thing cover to cover,

like 300 pages, just because I was like, I want to learn all of this stuff. And so I started with PICs. And so they weren't really that foreign to me because of that. Now, I've seen other microcontrollers that are simple but it's one of those things where once you learn picks it's kind of just like well everything that makes a pick difficult compared to everyone else is sort of just like well you can just deal with it you know i i guess i don't see the problem with picks um i've used probably every single microcontroller family under the sun. I would put PIX very low on that list that I want to use again.

But I don't see an actual problem with them. Especially the older ones, the data sheets are not very good sometimes. Oh, and we had experience with that. Yeah. Finding a footnote, figuring out gpio is not you know flipping around so but but when it all comes down to it i know i'm grossly like generalizing and making this too simple here but what i've personally found is that you know when you switch from one microcontroller to another most of the time you're still programming in C. Most of the time all of your stuff is generally the same.

You just have to scour the data sheet to find, oh, hey, this configuration bit needs to be that. Or I have to use these capacitors with my oscillator or blah, blah, blah. Like the rules generally stay the same between different families. It's just a matter of finding like whatever syntax differences you have to do to make it say hello you know yeah so i so so when it comes down to pics it's just like they're the family that makes me do these things whereas you know these this other one to pick any other microcontroller they're the family that makes me do those things i i'm biased against PIX because I don't like their programming interface and their fussiness with C.

Oh, you mean the MPLAB X or whatever? Yeah. It's a little bloated and confusing at first. And they're, I mean, they have some interesting things that you can do with interrupts and motors and whatnot. But they put a lot of burden on the programmer where other processors have taken more of that into their hardware abstraction layers or written more code for you that shows you how to do some of the more complex things. But PIC kind of throws you and says, eh, read our 300-page data sheet. I don't care.

Well, PIC really loves you to access individual bits within registers. Yes. And it loves to do bit masking and bit shifting. Like, to get into PIC, you need to know those things. And to be honest, I find that kind of fun. I actually like doing that but uh but i can understand that like the abstraction of hey this is like a pre-built-in motor driver within our pick where you all you do is write to a register and a motor does a thing like i can understand why that would be appealing see i i i'm a big fan of the parallax propeller and it's like the exact opposite of a pick yeah

i was about to say it has no hardware peripherals or things like that so you have to write everything um which is kind of interesting because you're basically right a like oh i need to have spy so i need to write software to emulate a hardware spy right but it's fast enough and it has enough cores that you can just well yeah do it you turn one processor into a hardware spy basically it's software still but it's dedicated to do spy yeah and since it has a whole bunch of little processors in there you just allocate them wherever they need to be right so so if you're not a fan of pics what are what are you a fan of well so arm standardized cortex and now you can get cortex from a number of different vendors pretty much everything's cortex m's i would it while i have used an MSP430 pretty recently, and I have used a couple of stranger TI chips, I prefer the Cortex's because there is less to learn between vendors.

I was about to say it depends a lot on the project. for the kinds of things we've been working on historically. They've been somewhat high-volume, very feature-rich kind of things, sensors and Bluetooth and stuff like that, which kind of pushes you to a different level. And I know PICs have higher-end ones, but... Cortex-M0 Pluses are pretty dumb and pretty small and pretty cheap. Compared to a PIC? Compared to an 8 or 16-bit processor, there are some out there that will compare well in the price range, yeah. And the power range?

Oh, yeah. Oh, okay. Well, that's fine. I don't know. I always thought it was funny that software engineers tend to prefer anything but PIC, and hardware engineers tend to prefer PICs. Always, always. Every time an EE has designed something and it has a microarch about it's like he learned picks and so he's like oh yeah i'll just grab i'll grab my bag of knowledge and plop it on the desk well okay so so i'll i'll do a little bit of a defense right here but this comes purely out of the fact that

parker can tell you without a shadow of a doubt i'm i'm not a software developer i'm not a programmer at all like i can i can dig my way through something and make it work but i'm nowhere near good at it so pics kind of i like the fact that that i know hey i write to this bit and i activated a thing like there's like a given trade right there like i pay that register money and it gives me what i wanted from it you know uh sort of a situation so it's like i like that really low level access to what i want something to do and and to be honest like what parker was talking about with the propeller um writing his own spy driver i actually did that on my first um pick also i just you know wrote my own function to do that that was all just a port call function basically with,

uh, with some like while loop delays and things like that. And it works, it worked fine. Uh, and, and so like, I,

I like having that, like I, I've always had trouble with like relying on other people's libraries or other people's like stacks of whatever they have going on just because it's just like a level of, I guess, I don't trust that or I don't trust myself to implement it properly. So I can just write it myself at the lowest level, almost assembly, and just it works. That comes from a non-programmer's mouth. It's a very understandable methodology. And it's one I kind of share because I really enjoy writing the code.

And reading code, even now, is harder than writing code for the most part. I'd rather read the data sheet and then write the code than read somebody else's code. But as even the smaller chips get more and more complex, I feel like I have to use some of these hardware abstraction layers or at least be able to read them and take out the pieces I want. Because more clients want the whole project done in a week because they they they think that that's possible well and you're you're giving away part of your chip if you not to you know not to attack you for bit banging spy we've all done something like that on some device but if there's a hardware

block that does it you should use it you should really use it it'll be faster it'll be using and even though it will take longer for you to implement initially, it will have the features you need. Well, and I don't know if it would take you longer necessarily. You always think it will. I was just about to say, I have a funny story about it. So yes, I've made both hardware and software spy drivers and things. I spoke to an engineering manager of a large audio company, gosh, a year and a half ago.

And we were talking just about a couple of their products. And he actually confided in me that they don't use any hardware communication drivers whatsoever. They don't trust the bare metal to do that. They write every communication driver in their firmware, even if their chips have a spy hardware level on it, which is interesting. It doesn't make any sense to me. It doesn't, but they don't trust it.

Their entire engineering team, and it's like 15 guys on this hardware team, and none of them, they will all write their own spy jobs. I have bad news for people who don't trust things like that. They should not get into cars, airplanes, boats, walk on the street, use computers. You're giving away so much of your time. And money. And money and effort towards something that is totally pointless.

Use the tools available. I mean, that's like saying, oh, I wanted to build a house, so I made a hammer. Well, here's the other thing, is those hardware blocks that are doing the peripheral things are verified by hardware engineers, right? There's chip verification. It's very rigorous. Writing a bit-banging software driver, driver i mean you're going to write bugs you write it once and you have bugs forever there is going there is an advantage of not using that kind of

stuff i'm still saying use hardware but like not using other libraries oh yeah sure sure um like the difference between um uh like let's just take arduino for an example like the arduino analog read first if you look online there's a library called analog read fast and it does it like a hundred times faster it basically just cuts out all the in between calls even even digital read and digital write on an Arduino are unbelievably slow. I feel like bringing up Arduino isn't fair. It's a bunch of libraries stacked on top of an IDE that are just guaranteed to make every call slow. Okay, so Arduino.

I love Arduino. I love Arduino. I really love Arduino because it helps artists and people new to development and it helps kids get interested in hardware and software. like your first first thing you ever talk to a new chip or whatever i'll usually try to see if there's an arduino library already just so i can get it working out of the box and then i port it over to whatever i'm using right but i do not agree with people who are using arduino professionally and i have so many reasons for that but what you're saying is exactly true. It's not fast. It's not efficient. It's really expensive for what it does. It's just not the right choice.

It's a great choice for prototyping and for getting into things and for just playing, for not worrying about, am I going to make a thousand of these just goofing off making the lights blink the fun part but once you're really serious about making something like professionally or commercially that is not the right choice so i'm not defending arduino as a software development environment um i guess if we're still on MyCook controllers and stuff like that My current favorite right now is the EFM8 platform by Silicon Labs

They're just cheap Like 40 cents in singles They're robust and you can get Fast versions or low energy Versions There's a lot of stuff you can do with them this is an 8051 what's wrong with that there's nothing wrong with that there's like millions and millions they made great music in the 70s code lines for that

and you know it doesn't even matter like if it's an 8051 under the hood. You're compiling C to it. It's not like you're having to look at, well, I look at the object code sometimes for time-critical stuff. Which this is probably a great example of where hardware guys, you know, look at it differently. Would just say, if it works, it works. Does it really matter what the processor architecture is and what that's going to be in the end? Oh, and if it works, no, it doesn't matter at all. But an 8051 is not going to be as power efficient

or as processing efficient as later developed cores. That's the thing, though, is I can't find... So I developed a product on it called the Macro Watch, which is a binary watch that runs on a coin cell. And in its sleep mode, it pulls only like 7 nanoamps. I think you calculated something like it has 10 years of battery life if you never turn it on. Yeah, if you never turn it on, yeah. But it will keep time has 10 years of battery life you know if you never turn it on yeah you never turn it on like but it will it will keep time for 10 years assuming your battery doesn't suffix

destroy but yeah that's an entirely separate issue but yeah it's like they're that's the sleepy bee line they all have like something b as their names um i really like it it it their ide can use a little bit more work um but it works well enough it's definitely better than arduino one i like their graphical representations of the chips and their pinouts and things like that that's kind of nice and they're really on the hardware end it's really easy too because they actually if you don't need timing constraints or anything you can just use the internal oscillator and all you have to do is get a bypass cap and it's pretty happy internal oscillators are awesome yeah and this one's even got like if you have an external clock it actually has they have like programmable loading caps so

you can set what the load caps are. So you don't even need external load caps. And they have a pretty wide range, too, right? Of what caps you can choose. If I remember right, there was a handful of caps you could choose. Yeah, but not the one I needed. Oh. Of course, right?

Yeah, yeah. It had to be that way so i actually had to um when i was setting up the loading caps because if you get it off because this is for like an rtc so you have to use a 32.768 kilohertz so for for timing yeah yeah yeah um i think that's the right number um but you had to load it right because if you don't load up those crystals right, you actually will get drift, and it won't oscillate correctly. And so I actually had to kept playing with what loading cap to use, and I got kind of close to where you'd get a one-second pulse

coming out of the chip. Right. I'm still not convinced with the 8051 but you just need to go to jay's one dollar microcontroller he talks all about it the the the micro control the one dollar microcontroller it does give that one a pretty high bar i mean it's not like they just took an old 8051 and yeah i know put new bells and whistles on it. It's actually got really powerful peripherals. Like the hardware it has is pretty impressive.

And that's what they do. They make a core that's super small and power efficient, and then they can turn off all of the peripherals they don't need. I think his biggest complaint was that when it's not in sleep mode and you've got the clock turned up, it's not super efficient. Yeah, it's a little hungry then. All right, cool. Let's see, moving on, I have other questions for you.

This one I liked a lot. If you could, like, Matrix-style learn a software skill, something you don't already know how to do. What would you, like, learn? Web development. Really? Like, making pretty web pages? Or, like, making deep... Applications. Databases.

So, like, AWS kind of stuff. Like, using React, JavaScript, and stuff like that. Why? Why? That's what everything's built in now but it doesn't change the physical world and that's the fun part it's a i mean i've been building things that changed the physical world all my life i've never built a web app like a purely soft thing yeah yeah i've never done it before and that's what

i've been kind of you know learning on the side is learning react and that kind of stuff because it's stuff i've never like like the first time i ever hit an api endpoint and i got data back i'm like holy crap that changed my life yeah like i waited 28 years to try that damn well i can tell you what i what i would do in fact we talked about this uh last thursday at the houston um hardware happy hour uh we had a group of hardware engineers all hanging out at a coffee shop around here and um I mentioned one of the things that I truly have no clue. It's magic to me. I would love to be able to write drivers for Windows.

What does that entail? What does that take? I don't know. How do I make bits flip on my device and Windows detects it in a way that is intelligent. You know, like that's magic to me. How do you want to plug it into your Windows box? Like USB? Sure, USB.

That sounds fantastic. Parallel port. Yeah, parallel. IDE, yeah. I mean, with USB, you have to get a microcontroller that can speak USB. And then usually those can pretend to be keyboards or they can pretend to be mice. He wants to write a real device driver. It's part of Windows.

I don't want to pretend. He wants to go through the Windows driver stack. I want it to be like the real thing. He wants to make the Cregulus Special 3. That's right. Yeah. Yeah. And so he would have to have a Cregulus driver.

Basically. It's not that I want to write it, I just want to understand it. To me, Windows feels like it has 8,000 layers before you actually get down to a bit turning on a transistor somewhere. I know the bit turning side, and I can move my mouse, but all the layers that are in between

are just a mystery to me. Well, where Linux has a very separated kernel and application space, Windows didn't have that for a long time. They didn't do as well at making it so that you have an administrator who can install drivers and a user who can use drivers. And because it took them so long, they kept having little layers that would protect slash allow until you have this monstrosity. And they kind of cleaned that up in Windows 10, Windows 9, Windows 8,

whenever they went to the... There was no 9. It was 7. Oh, okay, then it must have been 10. But it's still... I mean, if you wrote a Windows driver before, you can still see all the layers. That is an admirable

goal for understanding and very pointless. But if you want to do that, I would actually start with Linux. Yeah, I would start with Linux. Because the concepts aren't going to be totally foreign, and you can see everything. And then you start looking at Linux and POSIX and what it means to write a driver like that. And then if you wanted to go over to Windows, Windows would make a lot more sense, because it would have some of the same terminology and some of the same layers.

Well, okay, here, let's go on this topic real quick. You said it's pointless to do that. And I love that. I think that's fantastic. But explain to me why, from your perspective, because you have way more of knowledge about this. Why is that pointless? And I'm asking that, is that because there's a thousand people who have written things that I could just implement and they would just automatically work, or why? Windows doesn't want you to, because Windows has worked really hard to keep hardware more under control. And so they provide a wide variety of USB drivers,

because that's how most people plug in these days. And with the USB drivers, those are already in the layers, they already are well understood, and you can open up things. Now, if you go out and you get a Maxim USB chip or a STM USB chip, you're still going to have to fuss with the USB to make it so that it works. But the bytes will come in one after another. You won't be playing with the single pins that you want to play with. Because Windows doesn't want that. USB is already a standard. That's the fun part. I like that. You can make a PCI device. You can.

Then you can't? You can, but then why would you not use one of the billion PCI descriptors already out there? And it's kind of like for USB. If you could, you absolutely should use one of the...

And then if you're using a USB thing and you want to have your own driver for it, you're still writing on top of the USB stack. It's not as deep a driver as touching bits. Hmm. Okay. So, Stephen, you need to design your own OS now. Yeah, I think that's what I'm getting at. In order to touch bits, I need

Craig OS going on here. If you really want to look at it, the Windows DDK is the thing you're after. Driver Development Kit. I went to... So, I have sniffed a driver development kit before at a previous job we were doing something that required it and one of the other engineers was

there and he he was kind of walking me through what he was having to go through in order to do it and um i say sniff because it it was it smelled pretty bad it wasn't something that i wanted to even like touch because it was just like oh this looks horrible but that's what you want to do well that's why he wants to have it in theory i want to do it yeah i guess it's i guess it just purely comes out of a uh just not having a good understanding of it like oh i i'll take i'll give this as an example um I have a piece of test equipment back at home that is a voltage standard. So basically you flip switches on this thing and it outputs a voltage. And it's a really accurate voltage standard. Now it has an entire GPIO bus on the back of that,

which using whatever protocols they have defined in their data sheet, I could control this thing via however many ways I want to. Now, I like that because the data sheet just kind of tells me you do this and it does that kind of thing. And I love that just like down to earth GPIO. I have the connector here. I throw some bits at it and I get something out of it. That now the connection from there to some kind of higher level thing,

such as windows, that's where I'm like, I want to learn that aspect. And it's purely, I guess it's mainly educational for me more than like, I don't need to actually do it. Cause I know that there's a thousand ways that someone else has done it guaranteed way better than I could. I actually think Chris's suggestion of try it in Linux first is a good one. I mean, this is an instance where a Raspberry Pi would give you hardware access and let you build up whatever you wanted.

And then once you had that plan and could see the layers on the Linux side, it might make a lot more sense on the Windows side. Yeah, actually, you can probably just glue a Raspberry Pi to the back of this thing and do direct GPIO access on your Raspberry Pi. And serial port to the other side. You see, that part is

fairly simple. I've already done that on Raspberry Pis. I'm not saying that's boring or anything like that. I love the fact that the Raspberry Pi, you have a full computer that has an OS running on it, but if you want to talk to a pin, you can straight up do that.

I got it. Yeah, that's not fun at all. Put a Wi-Fi on the Raspberry Pi, so now your voltage standard is an IoT device, and you can just SSH into it over your network. That would be fun. And then run whatever you want. That would be a lot of fun.

Yeah, that's why there are so many Raspberry Pis on the net well okay add it to the project list yeah yeah okay what hardware skills should i learn as a software engineer who wants my doubly to appreciate me more um let's see so so i actually have one that i think would be fantastic and and and we have something well i believe you guys actually have something written out about this which is funny because i think both sides kind of argue about this same topic uh it's the idea of reading and interpreting schematics because both of us have to play by the rules of the schematic in a way and one thing that would be fantastic is for software people to be able to look at a schematic and get a lot of the answers that they need to not necessarily exactly how everything works or all the equations that go behind it but

things as simple as hey this is my input signal it It's going to this pin. And I can see that because it's this part of the schematic or something of that sort. So just a general ability to read a schematic is a very valuable skill, in my opinion, for a software developer. How did you learn to read a schematic? Did you learn to read it by writing it? Or did you ever learn to just read it by reading it? So I'm kind of weird, I guess. But so I kind of taught myself how to read schematics back in high school because I wanted to build guitar amps.

And I started downloading as many schematics because I knew that was the way that they were built but i didn't understand them so i just spent a ton of time looking at a bunch of them and reading a bunch of information until eventually i could identify all the individual components and you know it just grows from there i got mine uh reading um appliance wiring diagrams. So it's not quite as schematic, but it's kind of close. Yeah, repairing appliances and stuff when I was in high school. Okay, so you both did learn to read them before you learned to write them. Oh, for sure. Oh, yeah.

I learned to read them, but I always wondered if it would have been easier if I had been writing them first. Because now as I can sketch them, I can read them, but I always wondered if it would have been easier if I had been writing them first. Because now as I can sketch them, I can read them better. But it took me a long time to realize that there was a lot of the schematic I didn't need to follow. That there were whole pages I could kind of just mark off as, yeah, this is power conditioning. I don't care. Just give me my 3.3 volts and go on to the next page. Yep. That's actually a good point is like, maybe part if you're working on a team, part of your schematic is this is what matters for firmware. And this is what matters for software. Absolutely. And notes on the schematic are invaluable. So yeah, fill it up with notes as long as it's not super cluttered and you can still read it um i would say reading

schematics is probably the best way to improve your schematics that you're writing because you learn why isn't this explained and then you put it on yours right Right. And be logical about your schematics. I mean, chunk things into circuits that make sense to be together. You know, it does help to have a path through which signals flow. If you're a right to left guy or a left to right guy, it doesn't matter. Just pick one and stick to it. Stick to it. Yeah. Yeah, yeah. And have it such that, like, yeah, if you have, like you were saying, if you have six pages of signal conditioning that connect a thermal couple

to a processor, let your firmware guys know that, hey, pages one through six, you don't care about. Page six or seven is the one where your signal gets into the microcontroller or something like that.

Well, and you also should specify what kind of signal that is. Well, and you also should specify what kind of signal that is. So like if it's an analog signal, it'd be like, it's going to be in this range. Right, right. And you can expect these values in your code or something like that.

Well, that's a point I'd like to make because you say you can ignore parts, but what you're talking about signal conditioning sometimes we can't ignore that because uh there have been certainly instances where that hasn't been done quite right oh yeah and it bites us in the end because we have to end up fixing it in firmware with like oh we have to do this we have to reinterpolate this entire range because it's non-linear when we expected it to be linear or we have to correct it for some other thing. But there's a lot of cases like that where if somehow we'd been involved in

the analog design, which we can't understand, you see where I'm saying? Oh, yep. Well, but, but, but the way you're describing it, what that sounds like is, you know, not necessarily, I'm not saying like this is the end of the world or a horrible issue or anything like that. But it sounds like the hardware guys, maybe they either were relying on the fact that they were hoping that their prototypes would just work, or maybe their calculations weren't right. Or maybe they were expecting that we were going to do this in the future where we might have to you know apply a polynomial to whatever yeah uh and and and i think that goes

back to what i said a bit earlier about you got just just got to have communication between the teams um you know if somebody makes a decision such as hey i'm not sure if this signal conditioning part is going to work we're just going to have to try. Well, you know, that's an acceptable, you know, solution. Just make sure everyone knows that. And it's nice with the analog bits that I'm not following to be able to say, well, can you walk me through this? Especially if there's an answer at the end that says, expect voltages from one to three

volts. This goes into software. And then I'm like, okay, one to three volts. I can totally get that. What does that represent in physical units for the sensor? And then that's really awesome. When you do schematics, do you have lots of lines connecting things, or is everything net named, and then you have to search for the net names?

So, Stephen and I, we're different at this. We do it completely differently. I will, if it's ground or the power, in its logic block, so to speak, they are all connected and they will have a symbol or whatever. And if it's a signal,

if it's a signal that leaves the logic block, it gets net named. If it's inside the logic block, I usually will name the nets unless I – like, oh, there's no reason to name that net for some reason. Those all get connected. But yeah, so if you have like your power filtering over on one side and then your microcontroller on the other side, I don't go and connect the power good signal. So usually the things that I make into net nodes are power, sometimes ground, but a lot of times I'll draw out ground because a lot of the circuits I work on are very strict on how ground has to work. So power is almost always just a net name because it's just power. Now, I block things as much as possible on my schematics. So I'll put my whole microcontroller, and if I know it has off-board RAM that's next to it,

I'll put that right next to it on the schematic, and I will literally draw boxes around the things, and I will name those boxes. I will say, this is the USB input IC. This is the microcontroller. This is the memory. I will put notes all over the place on things, because it just helps things stick in my mind. Now, if it comes down to things like SPI, and I've got like 50 chips that are all on the SPI bus, I won't draw 50 lines everywhere. I'll just say, hey, this is the couple lines for SPI. I'll make those buses, and you can look at every chip and see, hey, this is an SPI chip because it accesses those buses. I've found that that's the easiest to read. And in general, my analog stuff is all physically wired.

I mean, not physically. You see the wires on my schematic, and my digital stuff is all blocks that are all named. This seems like a trend that has changed over my career. It used to be everything was wired together, and you'd end up with these schematics that were mazes. And I would feel like I was doing those third grade games where you have to follow the line. I remember getting out markers and trying to figure out where everything went because some of them didn't have names. And I remember in an

interview, somebody handed me a schematic that didn't have very many names and asked me what chip did what. And I was shocked to discover that I could tell which one was the flash chip and which one was a sensor just because I had enough experience looking at these things by then. But now it seems like nothing is connected and I have to do this game of trying to, this is the other third grade game where you have a list over here and a list over here and then you try to draw the lines in between to figure out what connects and i don't i don't like either way there's a balance for sure between the two like if if you're just naming every single

pin that comes off of a microcontroller its own individual name and then you have to hunt and pick for every single one it's annoying it really. That was how I used to do it. Yeah. I've seen some of Parker's old schematics and it's just like, oh, you just know it, but it's really hard to read. Even before that, because I learned by reading wiring diagrams is I drew them like wiring diagrams first. Oh, geez. So it was, everything was wired. Yeah. Yeah. Yeah yeah yeah actually if you want to have fun go to google and go look up the original schematics for the apollo guidance computer if you want to see schematics where every single thing is connected to every single thing

uh it's like i don't know how many pages for that original computer but it's like gate level logic no it's more than that it's far more far more than that and it's all gate level logic and they're all just connected to each other and they just have like page in and page out connectors named you know a ton of random things and they used to have the schematics be you know four by four i remember printing them out on the big plotter at work and it wasn't like eight and a half by elevens oh four foot by four foot yeah they were enormous and they would go on the wall i was like you said eight by eleven after four by four i'm like four inches by four inches yeah like you might get like two or three games oh what are we talking about coasters yeah well i mean that what they used to have a whole like army of people on uh drafting tables

writing all those up yep that was that must have been a lot of fun so so from from okay let's let's crack into the the software side of things in terms of schematics what would you prefer that we do that makes your lives easier definitely the thing you were talking about with putting blocks in common places and marking them having the schematic be part block diagram and part interconnection i think is super helpful because we don't really get block diagrams anymore. Yeah, block diagrams are really cool. Although I noticed in Altium, they're doing more with the block diagrams. A couple times now, I've seen the hardware guys use net names on the block diagrams that are then reused in different places inside. So like power, like they'll give power in different places.

And it means 3.3 on this side and it means five on that side. And I'm just like, shoot me now. And then the person who told me this then said, oh, it's object oriented. And I swear I almost shot him. But I'm much too nice for that. Wow. I was pretty violent. Sorry.

That's awesome. okay well we'll make sure we always have all of our power lines you know defined properly so what's the proper way to do that is it 3.3 3v3 oh i actually care as long as it's consistent hang on it's actually a question for steven i guess but the thing is like when you when you start getting into it sometimes you'll have a 3.3 digital and you'll have a 3.3 analog and those are different power supplies that you want to be different yeah go to different things and so we should have an a at the end uh i usually do um dig and ana at the end just to like make sure that it's like you know what it's going to. Yeah. Yeah. That's,

that's, so that's really what it all boils down to as clear as you can be, you know, if it, if it takes you an extra two seconds, you know, to, to, to just always ask yourself if someone else was reading this,

would they be able to get it? I think that's kind of one of the big things there. And everyone has their own way of, of doing it. I think that's kind of one of the big things there. And everyone has their own way of doing it. You know, you hand 10 projects to 10 hardware engineers, you're going to get 10 different schematics, and they're all going to have the fingerprint of whatever engineer did it. But they should all be readable at the end of the day. It's funny, in software, we have coding standards. And part of the reasons to do that is so that our code looks less individual have you is there ever been a hardware schematic standard i guess

there probably is i mean technically everything on a schematic is you know a standard like when you look at a transistor it should look the same every across everyone's computers however you know parker did did did they ever teach you how to draw schematic in college no no they like i i never once opened a uh a pcb program because of college i did it on my own you know uh and so you know anything we did was just like whatever wires we had to do in our lab notes to get by. I mean, I can think of three different ways to draw a resistor on a schematic. Right. There's a bunch of ways.

And it's different actually based off of where you are in the world. In the UK, they draw resistors as a box as opposed to a squiggly line. And so there are some standards. Angled squiggly line. Oh, I apologize. Because angled squiggly line oh i apologize squiggly line is inductor you're right you're right you're right line it's yeah yeah that's right yeah so yes yes there are standards and and we we like to pretend like we follow those i think he was talking about like the implementation of the hardware. We can talk about if you give us a project like

I'll use an EFM8 and then Steve would be like, I'm going to use a PIC for some reason. Well, I mean, I was, yeah, I do mean that, but also at the same time I was using a transistor, so let's run with that. An NPN bipolar transistor, the

emitter has the arrow pointed out out of it it should always point out regardless of how big or small or weird you draw it it should always point out such that you know that's the emitter it might not be a circle it might be a square it might be whatever i don't care whatever as long as like eventually i can read it i think that's where the standard comes in i really want someone to draw a really weird-looking NPN transistor schematic symbol now. Yeah, we should do that and then make a shirt out of it and then write MacFab Engineering Podcast on there. I actually didn't mean a standard for the components

because I guess I knew that that happened. Although it sounds like less than I thought. Yeah, a little bit less than I thought. I kind of viewed those in the same class as software keywords. It's like, no, you don't get any choice about those. You have to use those. I wondered if there was some standardization attempts towards net names and wire patterns

and how you put together... I'm sure individual companies put together yeah individual companies will usually have like a document like for that but no yeah that's the same as for code yeah there's no yeah yeah well there's i mean there there are attempts to get us to start doing coding standards and and people publish them. And people publish them. And some of our tools help us follow them. Local variables are all lowercase.

Global variables are all uppercase. Blah, blah, blah, blah, blah. That sort of thing. Yeah. There's more and more standards, like actual legit standards for this stuff when you're talking about defining footprints and packages. But even then, people don't care. That's the thing about it. People just don't care about those standards.

As much as we talk about them. I think I would make the argument that maybe they're not fully educated on them. And what I mean by that is a lot of people don't know that those standards exist. That's true. When you're just doing an 0805 surface mount resistor, do people know what IPC number document to go to that tells them how to do that? I would venture to guess nine times out of ten, they don't know what number that is. Don't you just get it from DigiKey? It starts with a seven.

No, no, DigiKey does not provide the layouts. And in fact, most companies will not provide those things because then there's some form of liability. If your circuit doesn't work or if it doesn't reflow properly or something, they'll give you guidelines, but they will not tell you exactly how to do it most of the time. You know, they'll give you pretty good guidelines. Are there – I heard something about a standard library of parts from a few vendors. Yeah, I think DigiKey just started doing that with KiCad. This is getting to

that kind of mentality with, I guess, hardware engineers. Because where Steven was talking about wanting to learn how drivers work and wanted to do it just to learn how to do it. And so it's his. That's how I think a lot of hardware engineers

are with packages and hardware is we don't trust That's how I think a lot of hardware engineers are with packages and hardware, is we don't trust what other engineers do. Oh, no. If Steven gave me a footprint, I probably would not use it. Other way around is probably true, too. Exactly. Why?

Tell me where people hurt you. When we first started with electronics, and the first time you spin a board, and it won't work because you put a SOIC-wide package instead of a SOIC-narrow. But you did that to yourself. No, you downloaded the footprint. I see, I see. You got somebody else's library.

You just trusted that they did it right. It looked good, but it didn't work. And the difference is when we hit compile, it takes three weeks instead of 30 seconds. And every time we hit compile, it's a lot of money. Yeah. Right. So the only way to, you know,

the thing is you own all of your mistakes if you make a mistake, but you also own all of your successes when you make it. And I'm not saying like that's like virtuous in any kind of way, but it is one of those things where like the way you know you did the design yourself and designed everything and you got it wrong you can just hate yourself you can't hate some random guy on the internet sure you can there are whole forums devoted to that i thought there was a point in the internet so i mean entering these footprints is pain, and it's not. It's tedious and boring and tweaky. That's the most fun part. I actually enjoy it, too. That's my favorite part of the job is actually finding a new part and being like, I get to draw this out and cat it out. And, you know, that's like the best part is finding those new parts that got weird packages.

Yep. you know that's like the best part is finding those new parts that are got weird packages yep and and you know a lot of the standards for these ipcs you know standards i was talking about a lot of times they don't tell you hey if you have a part that looks like this then do exactly this what they tell you is hey for this much pad coverage worth of solder, then you need to follow a 50% rule of blah, blah, blah, you know, things like that. So half the time, they're not telling you exactly what to do. They're just like, you calculate based off of statistics that we know that this is going to work 99% of the time.

And so you end up re-implementing these fairly complicated things over and over again. Or not for every board. Parker has his own library of resistors these fairly complicated things over and over again. Not for every board. I mean, Parker has his own library of resistors that he always uses. I have mine. And they're trusted because I've built boards in the past with them.

And so I know that that's always going to work for me. And I actually, like, let's say it's like an 0805 resistor. Like the one that the package I designed is actually in between what a purely machine-placed footprint would be and what a hand-soldered footprint would be. And it has some trade-offs on both of those. So, you can rework it by hand with an iron, or it will reliably go through the reflow oven but you give up like board space for that so let me tell you what this sounds like to me and i and i i see where you're coming from i really do because this is mechanical stuff and there's there's physical

things happening here but from my perspective this is like saying well every time i do a project i rewrite the operating system from scratch and i have some bits that i've written in the past but i always use my operating system that i wrote even if i'm making something you know an iphone app from a software perspective it's like okay well i mean i have everything i do i've made myself i mean I mean, that's not completely true. I mean, like, I will reuse all my footprints. It's not like I... But they're yours, right?

Sure. Yeah. No, I'm not trying to argue. I find it fascinating. It's a very different mindset from... Especially, I mean, I am going to talk tonight about a library in Python, and I don't think I really want to use this library, but I want to know about it. It's kind of like what you were saying about wanting to learn web development.

That's completely the other end of the spectrum, right? Where you're only piecing things together from other people's things. Yeah, you're not doing web development from scratch is actually i i'm not i do agree i'm not doing it from scratch but like when because i'm writing a lot of it in python and javascript it's like if i hit import and you know insert python thing yeah that you can import which is like everything. I actually will go to where that stuff resides and read it. How does that thing work? Because I just want to import

something and it does something else. Okay. I mean, I read the API about it, and I'll read a function or two if I'm unclear on the API, but I trust the APIs and then go on. And it's only when things go horribly wrong that I...

But like they say, when things go horribly wrong for them, it's money and time. And when it goes horribly wrong for me, it's just time. And let me also give you a little bit of a story. At a previous job, when we would do a new product, if it was just a prototype prototype usually there would be a handful up to like maybe three engineers who worked on it and they would kind of go off into a hole and do their own thing but when we were getting closer to going to production we would have a full design review where you know up to you know three to five engineers would go into a room for days on end and what we would do is we would go

every single item on the schematics. We would pull up the data sheet for that. We would pull up the footprint for that. We would measure everything. We would double check everything because every footprint was created. And to the company, that was actually more valuable to pay multiple engineers their full salary to do that than it was to order 20 boards and all of them be bad because one footprint was off or because one thing was off. The cost offset was good enough for that. So you each write your own individual operating system based on things you've done before and yet you believe in code reviews. Your company has a set set of footprints that's right yeah you know this company that i was talking about here they had been designing circuit boards

for 25 years so they had success placing a resistor it's you know over and over and over and over so we would use that resistor package it was trusted it was known it was good and it was to ipc standards you know but if we made a whole brand new funky sensor there might not even be It was trusted, it was known, it was good, and it was to IPC standards. But if we made a whole brand new funky sensor, there might not even be a package for that. You had to create your own package or some kind of weird chip that we didn't have in our library. You have to create it for that. So I think it's unavoidable in a lot of ways. You have code reviews.

You have detailed, in-depth code reviews of actual important information and not just fluffy names and stuff. It's odd because you have, as software engineers, we trust our libraries a lot more than you do, but we don't always get to have really good code reviews because we trust our libraries and we're throwing Lego blocks together. And if they stick, then yay. And if you get to have code reviews to say, oh, those two should be moved over, that's awesome. But a lot of times when you're working in a small team, you can't even do code reviews. I mean, isn't that what happened with the SSH bug that was, what, a couple years back?

The go-to bug? Is that the right one? I think it was the heart something. Did someone use a go-to statement? No, I think it was the heart thing. Heart bleed. Yeah. Was that the ssh bug that sounds right yeah it's interesting that was such a big thing at the time and now it's like

oh no heart bleed was ssl it was in tls that's it that's it yeah but it's like that was something that's been there forever and it finally took someone to look at it and be like, oh, oh, well, that's not good. To look at it, to understand, and to report. There were three points there. Yeah. But it's that same thing where, like, you know, at least someone could just press compile on that one again.

Well, and then update all the systems. Yeah, that's a tricky part. Everyone who uses it. Including the systems yeah that's everyone who uses it systems that aren't updatable yes well and and and you know not to beat a dead horse well i guess we can leave this as kind of the last thing let's say let's say that um you used a footprint on a board that worked it got through manufacturing everything is great and then 10 million units got out into the field. And you find out that because of your footprint, that something could make it fail in the first

two months of running. Then you're really screwed, you know? Then you would have said, oh, I wish I would have looked at my footprint and made sure that everything was right about it. But if you'd used a standardized footprint... I guess that's the question. Why aren't there standardized footprints that everyone agrees and has tested?

Why is there not one standardized software code? Well, we have only a limited number of operating systems to choose from. I mean, we do. We have the languages, and we can't deviate from them while using them. Well, I mean, you can use Python. Well, all I'm getting at is, like, you can use Python. You can use C++.

You can use C Sharp. You can use Rust. You can use... But it sounds more like you're saying you can mix and match them all together in one. No, so why isn't there a standard, like, language? One language to use all of them. It's the same thing in the hardware world where some footprints are better at other things than other ones. And I think, so a little bit further than that, if you go look at the standards for even the most basic component, a resistor, even the IPC standards will give you three separate footprints that you can pick from.

And they relate to three different manufacturing capabilities. If you want to do XYZ manufacturing in China, then pick this one. If you want it to go into space and be super reliable, then pick this one. And it's going to cost more and things like that. So the thing is, it's never just default. It's never just like pick one and you like that. So the thing is, like, it's never just default. It's never just like, pick one and you're good. I mean, for the majority it is, but it's not always going to be that case. Wow, I'm sorry.

That sounds really hard. I wasn't trying to be mean about it. No, no, no, it sounds really hard. That was a really good explanation. Yeah. Yeah. No, that's... So I wish it was that way. okay so i'll admit in in in some

cases that is true like the software package that i typically use for laying out boards is called dip trace and i have found just through experience that a lot of their basic level component uh footprints are acceptable like the soic style packages and things. The ones that are generally pretty easy to work with, they're good. And I will just use those. But I was really skeptical the first time I used it because I was like, I really don't know if it's going to work. And the good thing is you can open up their default libraries and check all the dimensions. So I did check all the dimensions and it was fine, but in a lot of cases I will just

rewrite that stuff. And also using somebody else's footprint, that footprint never looks like your footprints. And the text will be different and it's like, ugh. It's got to be my style. Like monsters.

It's like if you opened up somebody else's code library and they got a completely different style. They used tabs instead of double space. Those monsters. I'm actually a tab guy, so. Okay, so I actually have a quick question for you. I actually thought up this question earlier.

This is a little bit of a deviation, but still in the same world. So when it comes to a product, let's say that all four of us had designed a product together. Parker and I did hardware, and you guys did software and firmware. Let's say that we're going to need some kind of a change to that product. In your mind, should that start in the hardware team? Should that start in the firmware team? Who can initiate a change? The sales team. There should be a product team. Never give the sales team an opportunity to change something because they will. Well, usually, historically, there's a product team.

The things I've worked on where people are defining what the product is, what features it has. It depends on what the source of the change is, right? So if it's a bug, you know, is it something where we're going to have to rev the board? Is it something where we can do a firmware change? Is it a combination? And it depends. Yeah, it also depends where it comes from. Is it that there is no longer Flash of this size or the lead time is 28 weeks?

And so that definitely comes from hardware. Features for the user usually come from the software direction because that's who the product manager is complaining to because they think everything is software. I mean, there are system things. And a lot of the companies I've been to, you end up with either one hardware engineer or one software engineer or a pair who really enjoy working together

acting as systems engineers, if they don't have a separate role for that, who talk about, oh, you want to change the flash. Could you also make it better? Or could you also make it bigger? Or you want to change the flash. Could you, I only use a quarter of it. You can make it smaller if that's cheaper. And if you have those communication lines, it's easy.

But it does come to a big screeching halt when you're in production and the hardware engineer changes the flash, which has a different interface, and now you're in production and suddenly manufacturing has to stop because software no longer works and everybody in the company is screaming at the software team don't get me started and you triggered them pretty hard there and how do you i mean how is that the software engineer's fault there's a reason they get really angry at that point. But that's a failure of a systems engineer, or it's a failure of a management role,

or it's a failure of the two leads who needed to have talked. It's a team failure. That was actually another question I was going to ask, so let's just run with that real quick. If a hardware guy says, hey, I can shave five cents off by going to a different memory chip, how should he alert the rest of the team to say, hey, I want to do this, it's going to save us money? The nicest thing, the nicest thing that a hardware engineer can do

is to sit down and figure out the differences of the data sheet themselves, which they have to do. And then tell me about the differences. Ask me how long it will take. Like just in general terms, is this a week-long project or a six-month-long project? And definitely don't ask for like specific number of hours. You're just looking for a scale. Now you take that scale and you multiply, I don't know, multiply by your salary. You don't have to ask my salary.

Just multiply it out by how many hours that is and how long it would take and figure out if that five cents is actually going to save you money. Because engineers are quite expensive. And if you are only making a thousand of something and you're saving five cents on it and you're using a hundred engineer hours and not going to compute. So there's, so once you have the, how long is it going to take? Then you go back to your manager and you say, okay, they say it's going to take about this long. It will save us this much money in the next six months. Your manager goes talk to their manager. Their manager says, oh my God, you talked to the hardware engineer? Why did you do that?

Or no. You're not supposed to talk to those people. They're cave trolls. And now you have a value proposition. You're not changing things for a small thing. You're changing things to make the whole system, the whole team, the company better. And it doesn't feel like it's just, oh, I'm changing things because, I don't know, some vendor took me out to lunch, which I swear I have felt that way. The only reason this changed was because someone got a good lunch out of this.

I mean, I would do that. I'd change a part if I got a good lunch. Well, because you're just changing the footprint and I have, I would do that. I'd change a part if I got a good lunch. Well, because you're just changing the footprint and I have to do all the work. You should have taken me out to lunch at least too. Yeah. That's a good point. I really like the idea of making sure you come at it from a team and systems perspective, even though that makes it a little bit harder. But as you said earlier, if you spend an extra 20 seconds or an extra

20 minutes making someone else's life an hour or two easier, then you've won. It's a team sport these days. I know we're all individuals, but it's still, sadly, a team sport unless you're making your own footprints.

If we were all here, we could have a big group hug yes that's actually a really good point to leave it on unless you all would like to have final thoughts closing arguments closing arguments one more debouncing a button

firmware or hardware Parker's asked me this one before uh hardware because i'm lazy uh it depends on the quantity if it's more than 10 000 then i'll do it in firmware but if it's less than 10 000 buy your own capacitor i think the last time I answered this, I said both. I implement, I usually implement both. Belt and suspenders. Well, if you talk about like FCCCE testing and stuff,

it makes a lot of sense to do it that way. Yeah, I mean, it's wise in software to always debounce your buttons or to admit that you don't really care if you hate your user and have them you know okay and and here's a quick gripe that is totally off topic way big tangent something that i think really needs to change and i don't know if this is a hardware or a firmware thing but when you're at the gas pump any gas pump it doesn't matter pick any single one why are the computers so damn slow like okay so if i if i press a button it should just go you should hear christopher's rant about point of sale systems and how awful i think they're all slow i'll answer it this way. Lowest bidder.

Oh, yeah, yeah. Okay, that makes sense, yeah. Just make them a little bit faster. The only thing about making it slower, the only thing it hurts, is the guy who wants to go fast. Everyone else could go slow if you want to. They could sell more gas if they could put people through faster.

Yeah, there goes the money. There we go. You see the new gas stations, right? They have that have like ads and stuff on yes and they yell at you that's where all the computing power is going video decoding yeah yeah it's not going to the buttons that's for sure the ads buffer quickly it's actually like when you have to type in your zip code that takes forever oh my god it's horrible and then you accidentally hit cancel and it's game over if you do that like you're usually when that happens just change pumps yeah no i've done that i've literally driven to another pump yeah uh i that's my closing

argument there all right yes well this has been a crossover show of the Macrofab podcast with Stephen Craig and Parker Dillman and the Embedded FM podcast with me, Eliseo White, and my co-host, Christopher White. You can find both podcasts in your normal podcast app or look on their websites, macrofab.com under blog or embedded. FM under embedded. Embedded. FM. Thank you to Christopher for editing as well as being my cohost and producer. Thank you to Steven Craig and Parker Dillman for joining us. And of course, thank you for listening.

I have a final thought to leave you with, because this is something we do on the embedded show. And my final thought this week is from the painter Bob Ross. If we all painted the same way, what a boring world it would be. If we all drew footprints in the same way, what a boring world this would be. 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.