The engineering mind. Stephen and Parker discuss if the process engineers use to solve problems is inherent to engineers or is there something more?
Texas Instrument SOIC package oddities? Has Stephen unearthed some counterfeit components or is it just a new manufacturing process from TI?
Is grinding out math problems just busy work? Is the current state of Math class curriculum hampering the real life deployment of engineering skills?
Visit our Slack Channel and join the conversation in between episodes and please review us, wherever you listen (PodcastAddict, iTunes). It helps this show stay visible and helps new listeners find us.
Embedded.FM logo
Elecia White and Christopher White (right to left).
Parker is an Electrical Engineer with backgrounds in Embedded System Design and Digital Signal Processing. He got his start in 2005 by hacking Nintendo consoles into portable gaming units. The following year he designed and produced an Atari 2600 video mod to allow the Atari to display a crisp, RF fuzz free picture on newer TVs. Over a thousand Atari video mods where produced by Parker from 2006 to 2011 and the mod is still made by other enthusiasts in the Atari community.
In 2006, Parker enrolled at The University of Texas at Austin as a Petroleum Engineer. After realizing electronics was his passion he switched majors in 2007 to Electrical and Computer Engineering. Following his previous background in making the Atari 2600 video mod, Parker decided to take more board layout classes and circuit design classes. Other areas of study include robotics, microcontroller theory and design, FPGA development with VHDL and Verilog, and image and signal processing with DSPs. In 2010, Parker won a Ti sponsored Launchpad programming and design contest that was held by the IEEE CS chapter at the University. Parker graduated with a BS in Electrical and Computer Engineering in the Spring of 2012.
In the Summer of 2012, Parker was hired on as an Electrical Engineer at Dynamic Perception to design and prototype new electronic products. Here, Parker learned about full product development cycles and honed his board layout skills. Seeing the difficulties in managing operations and FCC/CE compliance testing, Parker thought there had to be a better way for small electronic companies to get their product out in customer's hands.
Parker also runs the blog, longhornengineer.com, where he posts his personal projects, technical guides, and appnotes about board layout design and components.
Stephen Kraig began his electronics career by building musical oriented circuits in 2003. Stephen is an avid guitar player and, in his down time, manufactures audio electronics including guitar amplifiers, pedals, and pro audio gear. Stephen graduated with a BS in Electrical Engineering from Texas A&M University.
Special thanks to whixr over at Tymkrs for the intro and outro!
Welcome to embedded I'm eacea White alongside Christopher white. Our guests slash co hosts are Stephen Craig and Parker Dillman of macro fab and hosts of the macro fab podcast. Hey, everyone, crossover. Sorry. Say I'm Parker.
And I'm Stephen. And we're from the macro fab engineering podcast.
And I'm Chris from better.fm. Podcast and
Emily's. Yeah. From embedded.fm. Podcasts and logical elegance and all of the other insane things I get into those as well so far. Oh, yeah. Whoo, 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.
Um, yeah, I'm Parker Dohmen. I'm electrical engineer. Born and raised in Texas, started our co founder of macro fab. And it's been my life for what the last four and a half years now. Do electrical, you know, manufacturing for small OEMs specializing in doing prototypes and small volume runs stuff like that. I like Jeeps I like hunting, camping, fishing, taking things apart. So it's probably what got me into all this.
So. And I'm Steven Craig, I'm also a native Texan. For the majority of my life, not originally, but the majority.
i How can you be a native partially a native Texan?
Because I have I have given up my Oklahoma resident ah, that is no longer I'm officially a Texan. So I am a general purpose engineer at macro fab. I have been at macro fed for two and a half, three years, something like that. Yeah. 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 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. Well, I'm a sia white, 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, somewhat,
sometimes from like, I'm knowing people to like to write.
And now it's at one, I've been abandoned.
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 start up 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 are a lot more brown, and kind of nasty. So I'm excited about 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 gonna 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
find out what's wrong with the other side.
I was gonna say want from each other, but we can go with what they hate about each other instead,
that works to 10 Things I Hate About.
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 max web engineering podcast actually was created just so we could. We had a blog on our on our website, Max web.com. And 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 we were writing, I was writing articles at the time, this is before Stephen Emery came on. Because I was writing articles. At the very beginning, it was just me writing articles, and I could get like an article out every like three months. So it's really slow. And then well, cuz at the time there was like, Yeah, well, at the time, we had like six people here at macro fab. And so like, I was running the assembly line, I was doing like 80 different things. So writing the article was so far back, you know, on the backburner. And so we're like, Hmm, 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 publish those and people seem to like it. And so we went to a studio and started recording. And now we have our own equipment. The big thing I like to I try to hammer home with our podcast is it's not an advertisement. I don't like promoting Mac fab on the website on the on the blog, podcast. And I like to talk about engineering in 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 no fun thing that we get to do every week.
Yeah. Yeah. And you do you have guests, but you also talk about news and what's current and all that we usually avoid news and focus on guests. Do you have any favorite topics you like to hit?
how shitty IoT is? That's a recurring topic? Yeah.
There's been plenty of those for sure. And and if you if you look back, there were there's kind of two ways to describe one way for each one of us it would be Parker equals jeep. And Steven equals synthesizer that to reoccurring ism both of those are reoccurring topics for us, because we both do a lot of work in those I know and it'll it'll be something where if you listen from the beginning, you can hear Parker's Jeep evolve through. It's almost sensing it now. 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. No,
need to combine the two, some sort of cheap synthesizer? Oh, that'd be great.
Okay, that's, that's one of the biggest problems. I'll say that this is a problem with our 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.
List of Christopher's project on one show, and it was like 25 things long and made him give him updates, give updates on all of the projects. And it was
30, and they're also in the same status.
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 soapbox, and
it's tough because you do want to talk about interesting stuff. But how do you do interesting stuff every week. Realistically, we have jobs, we do technical things we can't talk about. And so for our hobbies, we're gonna do extra electronics. And then we're gonna make a podcast about it.
Actually, that's kind of how it works. We usually like alternate, which ones project is like 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,
and you're scrambling the night before the podcast
is this way you started having guests a lot?
Ah, 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 typically ask us or, well, yeah, people get bored. Yeah, they don't want to keep hearing about jeeps and synthesizers they want to hear about something else. But no, like we just we just have more opportunities for guests. So works out. 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 like, say, Hey, be on the show. And then I can ask them all my personal technical questions and not have to go through like support for
your own personal FHP. Right.
We actually sort of had that the other week when we we had a patent lawyer on Oh, yeah. And, and and what 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 your businesses and taxes. And it was tiny, and that one outside the scope of what we usually talk about, but it was fun, and I think a lot of people listened to.
That's great. Okay, well
till we get to the actual, how to make stuff. How to make software and hardware engineers work better together. Wow, that 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 macro fab one of them?
No, it was the previous company I worked with, which was dynamic exception, with church, which is our co founder here at Mac fab. He was the other founder there at Dynamic perception. And he was the person who's writing all the code, and I was designing the hardware. So this is it's this is gonna be very interesting podcast, because I haven't really worked like this before, like, but these two separate, like I use for my personal projects, I write all my firmware. Now, I write it poorly. But I try
well, and I think a lot of your projects. They're large, but they're not of the scale that requires a team.
Well, that's true, too. Well, no, no, the Pinball Controller has a dev team now. That's true. Yeah. So maybe I'll learn something to how to manage that. Because I've no idea what I'm doing. Yeah, you'll
learn why they hate us, I guess. Yeah. So I've worked on some teams before, where I've actually had a 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 micro that was on my boards, and then the the the person doing the software, she wrote all the code for, you know, the test programs and things like that. So I have a little bit of experience of working, you know, hand in hand everyday with Ana with software goes.
That's funny. I don't work as closely with hardware guys as I used to, because I'm doing more startup work. And they want breadboard so that they get prototypes, so they get venture capital. But I end up buying my boards off of tindy or Adafruit or SparkFun, or Alex press, and just slapping them together and hoping that nothing really goes wrong with that plan. But I used to, I used to sit next to my family, I used to share an office with my Dubli. And and we would talk every day. It's weird to have more separation than there used to be.
Well, as the companies get larger, separation gets further and further. Yeah, different departments. 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 firmer review by hardware people. But still an unfortunate sometimes. Yeah, and then lots of miscommunication and, 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 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 it comes 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 those people make a change to a product, it affects everyone else. And so you really have to, you have to have real strong communication with your software people and your firmware. or you will get you know, you will result in anger, I guess what you put it?
Well, I don't know. I mean, it depends on your definition of firmware that's kind of loose.
It's, 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 macro fab. 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, those people
argue 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, so hardcore gatekeeping? Yeah, you must write an object or assembly code to be firmware
to I mean, from where 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, or
there isn't a solid line in the stuff I do every day? No, I mean, I'm people would define what I do in the morning of software, and maybe the afternoon is firmware. 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.
You were just complaining about you were having arguments with both the hardware engineers and the design team. Because there was no real design team, there was 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 bedded?
Oh, God, not again.
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. Hmm.
So it's a sliding scale, in a way depends on what you use it for what you what part of it you're working on. Yeah.
But of course, there are things like Fitbit or microwaves, or even cars, the you have to say, those are 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 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 run a Python program that runs on it,
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. That mean, well, okay, how about this example, I worked on medical imaging scanners that the main core was a Windows computer. And embedded system, they did one thing?
Yes, definitely.
Yeah. reflow oven that has Windows XP on it. So I mean, it does one thing reflow boards. Yeah,
the the self checkouts at Home Depot, all run PIC microcontrollers, they are embedded systems, they do one thing.
And the Raspberry Pi. I don't 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 ahead. 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 I think it's it can be unuseful to to discuss this discussion,
where you get jump right to like the meta side of the differences between hardware and software.
I think you know, something that interacts with the real world something it has a single purpose. That's probably a pretty good you pass butter. Yeah, you pass.
Okay, but we know what hardware is doing even though hardware isn't as clear cut as it used.
FPGA seems like,
yeah, yeah, flat flex. PCBs. They're not real hard.
How do you feel about this? I mean, I see a lot of hardware engineers using them. And I'm like, No, you can't solder to them. Right? And then they come back. They're like, Oh, it's totally fine. And then, like after five of them have burned on their soldering iron there. Oh, I wish I'd used a real board.
Oh, I we solder flat flex all the time here. It's not a problem.
Yeah. And there's there's purpose built soldering irons, the winter column, hot bars, they call them hot bars for purpose built for flat
flicks. They're just really, really wide soldering tips
on an arbor press, basically. So,
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 to get hot enough so that it's actually sometimes it's even hotter. So it gets a higher impulse with less soakage heat soakage.
Okay. That makes sense. I still don't I still don't love flex, because I definitely cannot sat around them. And I have watched my hardware engineers, flame, flex
their expensive flex connectors.
And then you're like, I shouldn't laugh. I shouldn't laugh, I shouldn't.
Awesome. Go back to the we're talking about if Chris was talking about what hardware is like. So he saw he brought up the example FPGAs, which is very interesting. Because is 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
to restore, like a picture, in a way.
Hmm. I've always thought about it as logical, a logical definition of how things are clocked and what to do when certain clocks happen. And it seems more like C code to me, except while at once.
Yeah, it's it's a lot like C code. But the thing is, oh, it's C code that what kinda likes with like, not Verilog. It's kinda 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 mad. 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, right.
You could actually write a schematic of what you asked the FPGA Oh, whole gate logic you could if you really wanted to,
really wanted to?
I mean, people do. Yeah,
I mean, that would be horrible. But somebody out there probably does do that.
Well, the in school the first time you program an FPGA, you do it with gate logic, you draw out all the gates and connected together. And then once you learn VHDL or Verilog, you like why did they make us do that?
I'm never doing that again. Right? Yeah.
Okay. Let's see, we have we have actual questions here. Oh, right. There was this one. This one is a big baffling question for me. You like picks? Like really? Like you like picks?
What? Okay, so that probably,
that's probably just Steven. Yeah, that's probably okay. So
I'll give I'll give just a short story on it. picks are, I do like them and, and one of the reasons why I like them, or a chunk of the reason why I like them probably has to do with nostalgia. So at my school, I studied mainly semiconductor physics and analog electronics. I did very little digital electronics at my school. And that was by choice. It just it didn't interest me on it wasn't, you know, 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 decide to go with pic and I taught myself everything microcontrollers, based on pic architecture, and I literally just got a datasheet 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 they weren't really that foreign to me, you know, because of that. Now, I've seen other microcontrollers that are simple, but it's one of those things where once you learn pics, it's kind of just like well, everything that makes a pic 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 pics. I've used probably every single microcontroller family under the sun. I would put pics very low on that list that I want to use again. But I don't see like an actual problem with them. They're, especially the older ones, the data sheets are not very good sometimes. So and we had experience with that, yeah, finding a footnote figuring out why 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 and see, most of the time, all of your stuff is generally the same, you just have to scour the datasheet, 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 that 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, so, so So when it comes down to picks, it's just like, they're the family that makes me do these things. Whereas the, you know, these this other word, pick any other microcontroller, they're the family that makes me do those things.
I am biased against pics, because I don't like their programming interface. And they're fuzziness with see
how you mean, the MP lab? Or whatever? Yeah, it's, it's, it's a little bloated and confusing at first.
And, and they're, I mean, they have some interesting things 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, Read our 300 page data sheet. Okay.
Well pick pick really loves you to access individual bits within registers. Yes, and it loves to do bit masking and bit shifting, like it to get into pick, you need to know those things. And to be honest, I find that kind of fun, I actually like doing it. But, but I can understand that like the abstraction of hey, this is like a prebuilt 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.
Say I a big fan of the parallax propeller. And it's like the exact opposite of a pic. Yeah, it has no hardware, peripherals, or things like that. So you have to write everything. 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 you turn one processor into a hardware spy? Basically, it's software so 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 if you're not a fan of pics, what are you a fan of?
Well, so arm standardized cortex and now get cortex from a number of different vendors. Everything's protects EMS, I would it while I have used an MSP 430 pretty recently and I have used a couple of Stranger ti chips. i i prefer the cortex is because there's less to learn between vendors 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 than I know pics have higher end ones but
Cortex M zero pluses are pretty dumb and pretty small and pretty cheap. Compared to a pic. Compared to an eight or 16 bit processor. There are some out there that will compare. Well in the price range. Yeah.
And power range. Oh, yeah. Okay. Well, that's fine.
I don't know. I always thought it was funny that software engineers tend to prefer anything but pick and hardware engineers.
Always. Every time he has designed something, and it has a micro because oh here here's this and here's a pic 16 doing so
I think it depends on how old the engineer is and what they learned. It's it's, it goes what Stephen was talking about. It's like he learned picks and so he's like, oh, yeah, I'll just grab. I've grabbed my bag of knowledge and plop it on the desk.
Well, okay, so so I'll do a little bit of a defense right here, but this guy 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 picks 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, sort of 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, writing, get his own spy driver, I actually did that on my first pick. Also, I just, you know, wrote my own function to do that, that was all just a port call function basically, with, with some like, while loop delays and things like that. And of course, it worked fun. And so like, 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 programmers mouth.
It's a very understandable methodology. But 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 datasheet and then write the code than read somebody else's code. But as there is, the smaller it is, even the smaller ships 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 think that that's possible.
Well, and you're you're giving away part of your chip, if not to not to attack you for Big Bangs by 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 just be more,
it'll be faster, we'll be using our CPU. Yeah. And even though it will take longer for you to implement initially, it will have the features you need.
And I don't know if it would take you longer necessarily,
mentally, Theo's. Thank you. Well,
I was just about to say like, I have a I have a funny story about it. Because so so yes, I've I've made, you know, both hardware and software, Spy drivers and things. I spoke to a an engineering manager of a large audio company, gosh, a year and a half ago. And we were talking just, you know, about a couple of their, 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 like a spy hardware level on it, which is interesting, doesn't make any sense. It doesn't, it doesn't, but they don't, 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 read
news, who don't trust things like that think they should not get into cars, airplanes, boats, walk on the street, and 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? That's there's chip verification, it's very rigorous. Writing a Big Bang software driver. I mean, you're gonna write books
you write at once and you have bugs forever.
There is going there is a an advantage of not using that kind of stuff. I'm saying use hardware but like not using other libraries. Oh, yeah, sure. Sure. Um, like the difference between like, let's just take Arduino for an example, like the Arduino verse. If you look online, there's a library called analog read fast and does it like 100 times faster and basically just cuts out all the in between calls.
Even even digital read and digital right on 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 it. IDE that are just guaranteed to make every call slow.
Okay, so Arduino. I love Arduino. I really love Arduino because it helps artists and people new to development and, and it helps kids get interested in hardware and software.
I mean, I'll admit, I use it time to time too. It's really good at prototyping, like your first first thing, you ever talk to a new chip or whatever, I'll usually try see if there's an Arduino library already, just so I can get it working out of the box. And then I ported 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 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 1000 of these, just goofing off making the lights blink, the fun part. But once you're really serious about making something a professionally or commercially, that is not the right choice. So I'm not defending Arduino as a software development environment.
I guess if we're still on microcontrollers, and stuff like that, like my current favorite right now is the EFM eight platform by Silicon Labs. They're just cheap, like 40 cents and singles.
That robust and you can get fast versions or low energy versions, and there's a lot of stuff you can do with them.
This isn't at 51, you know,
that. There's nothing wrong with that. There's like
millions and millions, they make great music and authorities code lines.
And, you know, it doesn't even matter. Like, if it's an ad 51 Under the hood, you're not even 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, but
which, which this is probably a great example of where hardware guys, you know, look at it differently. We just say if it works, if it works, does it really matter what you know, what the processor architecture is, and what that's going to be, you know, 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 course.
That's the thing, though, is I can't find so I developed the product, I project on a product on it called the macro watch, which is a binary watch, it runs on a coin cell. And that is in its sleep mode. It pulls only like seven nano amps.
I think you calculated something like it has 10 years of battery life. You know if you never turn it on? Yeah, I never turned it on. But it will it will keep time for 10 years.
Assuming your battery doesn't suffer. Destroy. Yeah, that's an entirely separate
issue. But yeah, it's like their, that's their sleepy B line. They all have like something B as their names. I really like it, it it. Their IDE can use a little bit more work. But it works well enough. It's definitely better than Arduino one.
I like their graphical representations of the chips, and their pin outs and things like that. That's kind of nice.
And they're really on the hardware end, it's really easy to 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 need load cap external load caps.
And they have a pretty wide range to write of like what caps you can choose. For remember, right there was there was like a handful of caps you could choose
Yeah, but not the one I needed.
Of course, yeah. So it had to be that way.
So I actually had to wipe 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.7 68 kilohertz support for timing. Yeah, yeah, I think that's the right number. 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 kept us and I got kind of close. To where you'd get a one second pulse coming out of the chip.
And I'm still not convinced with the ad 51 But I
just think Jays $1 microcontroller he talks
about it did the microcontroller $1 microcontroller, it does give that one a pretty high bar.
I mean, like, they just took an old at 51. And yeah, I know put new bells and whistles on slap, 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. Yeah.
Alright, cool. Let's see. Moving on. I have other questions for you. This one I liked a lot. If you could Matrix style, learn a software skill is something you don't already know how to do. What would you like,
learn web development? Really,
like making pretty webpages or like making
applications stated to like a ABA, like AWS kind of stuff? Like using React JavaScript and stuff like that? Why? Why? That's what everything's built in now.
But he doesn't change the physical world. And that's the fun part.
It's a I've been I've been building things that changed the physical world all my life. I've never built a web app. Like I'm purely soft. 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, look, I
waited 20 years to try that damn.
Well, I can tell you what I would do. In fact, we talked about this. Last Thursday, at the Houston, hardware happy hour, we had a group of hardware engineers all hanging out at a coffee shop around here. And I mentioned one of the things that like, I truly have no clue. Like, it's magic to me. I would love to be able to write drivers for Windows, like, what does that entail? What does that take? I don't know. Like, how do I make? You know, bits flip on my device, and Windows detects it in a way that is intelligent, you know, like that. That's magic to me. How do you want to plug it into Windows box? USB? Sure. USB, that sounds fantastic. parallel port? ID? Yeah.
I mean, USB, you have to get a microcontroller that can speak USB. And then usually those can pretend to be keyboard or they can pretend to be
three, right? A real device driver there.
I don't want to Yeah, I don't want to be like the real thing.
He wants to make the Craig Ulus. Special three? That's right. Yeah. Yeah. And so you'd have to have a credulous driver,
basically, like, it's not that I want to write it, I just want to understand yeah, like I like, to me, Windows feels like it has like 8000 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.
Oh, 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 nine Windows eight whenever they went to seven. Oh, okay, that must have been 10. But it's still. I mean, if you wrote a Windows driver before, you can still see the layers. That is an admirable goal for understanding and very pointless.
But if you want to do that, I would I would actually start with Linux. Yeah. Because it's the concepts aren't going to be totally foreign. And you can see everything
and then you start looking at At Linux and POSIX, and what it means to write a driver like that. And then when you, if you wanted to go over to Windows, Windows would make a lot more sense because they would have some of the same terminology and some of the same layers.
Well, okay, let's, let's, 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 way more of knowledge about this. Why is that pointless? Because and I'm asking that is that because there's 1000, people who have written things that I could just implement, and they will just automatically work or why
Windows doesn't want you to, because Windows has worked really hard to keep things 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 layers, they already are well understood. And you can open up things. Now, if you go out and you get Maxim USB chip or STM USB chip, you're still going to have to fuss with the USB to make it so that it works. But the 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
a PCI device.
You can't, you can't you can. But then why would you not use one of the billion PCI descriptors are already out there. But it's kind of like it for USB. If you could you absolutely. Mind device, one of the but and then if you're using a USB thing, and you want to have your own driver for it, you're still riding on top of the USB stack. It's not as deep a driver as touching bits.
Okay, Steven, you need to design your own iOS now.
Yeah, that's, I think that's what I'm getting at in order to touch bits I need I need crago s going on. If you
really if you really want to look at the the windows DDK is the thing here. Yeah, after Driver Development Kit.
Oh, I you know, so. So I have 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 I say sniff because 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 do it. I guess it's I guess it just purely comes out of a job just not having a good understanding of it like, Oh, I'll take, I'll give this as an example. 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 you know, using whatever protocols they have defined in their datasheet, I could control this thing via however many ways I want to. Now I like that because the datasheet 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 a 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. Because I know that there's 1000 ways that someone else has done it. Guaranteed way better than I could.
I actually think Chris's suggestion of try and Linux first is a good one. I mean, this is this is an instance where a Raspberry Pi would give you a hardware access and let you build up whatever you wanted. And then once you had that plan and could see the layers on the on the Linux side. It might make a lot more sense on the Windows side.
Yeah, actually, you can probably just glue Raspberry Pi to the back of this thing and do direct GPIO Axis on your Raspberry Pi and
in serial port to the other side just to see
that part. That part is fairly simple. Yeah, I've already I've already done that on on Raspberry Pi's. I'm not saying Like, that's boring or anything like that. I love the fact that the Raspberry Pi, you have a full computer that has an iOS running on it. But if you want to talk to a pin, you can straight up do that. I got it. Yeah, that's
the wife, 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, that's why there are so many Raspberry Pi's on the net.
Well get added to the project list. Yeah, yeah.
Okay, what hardware skills? Should I learn as a software engineer who wants my web to appreciate me more? Um,
let's see. So I actually have one that I think would be fantastic. And we have something, why believe you guys actually have something written out about this, which is funny, because I think both sides kind of argue about the same topic. 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's going to this pin. And I can see that because it's this part of the schematic or, you know, 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?
I 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 mind reading, appliance wiring diagram, so it's not quite a schematic, but it's kind of close. Yeah, repairing appliances and stuff when I was in high school. So
okay, so you both did learn to read them before you learn to write them?
Oh, for sure. Oh, yeah.
I always, 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, my 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 are 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 what matters for software?
Absolutely. And notes on the schematic are invaluable. Yeah. So So yeah, fill it up with notes, as long as it's not super cluttered, and you can still read
it. 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 and 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 or right guy, it doesn't matter. Just pick one and stick to it. Stick to it. Yeah, yeah. Yeah. And and 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 thermocouple, to a processor, let your firmware guys know that, hey, pages one through six, you don't care about Page Six is or seven is the one where your signal gets into the microcontroller or something like
that. One, you also should specify what kind of signal that is. So like, if it's an analog signal 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 the that's the 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 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 re interpolate this entire range because it's nonlinear. We expected it to be linear, or we have to correct it for some other, but did a lot of cases like that. Where if somehow we'd been involved in the catalogue design, which we can't understand isn't where I'm saying? Oh, yeah, yeah, 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 hotel 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. And and I think that goes back to what I said a bit earlier about, you got to just just gotta have communication between the teams. 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, that's an acceptable, you know, solution. Just make sure everyone knows that. Yeah.
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 and then I'm like, okay, 123 volts, I can totally get that. What does that represent in physical units for the sensor? And then that's, that's really awesome. When you do schematics, do you? Do you have lots of lines connecting things or is everything net named, and then you have to search for the net names.
So on from Steven nine different ways to do it completely differently. I will its ground or the power in its logic block, so to speak. They are all connected, and that you will have a symbol, whatever, if it's a signal, it is a signal that leaves the logic block, it gets net named, it's inside the logic block, I usually will name the nets unless like, like, oh, there's no reason to name that net for some reason. There's, Oh, get connected. But um, 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, like the power good signal.
So So usually, the things that I make into like 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 home microcontroller. And if I know it has, you know, off board RAM that's next to it. I'll put that right next to it on the schematic. And I will literally drive 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 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 you know, 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 that physically, you see the wires on my schematic, and my digital stuff is all blocks that are all named.
But this seemed like a trend that has changed over my career I 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 with 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 To 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 peck for every single one. It's annoying. It really is. That was how I used to do it. Yeah, I've seen some of Parker's old schematics. And it's just like, oh, so there's just no it but it really
was read even before that, because I've learned by reading wiring diagrams is I drew them like wiring diagrams first. Oh, geez. Everything was wired.
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. It's like, I don't know how many pages for that original computer, but it's like gate literally 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, autonom 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
1104 foot by forefoot. Yeah,
they were. They would go on the wall.
Like you said eight by 11. After four by four. I'm like, Oh, my forges kit like three gates. I waited we talked about coasters.
Yeah, well, they I mean, that what they used to have a whole like army of people on drafting tables, right? 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 a schematic P part block diagram and part interconnection, I think it's super helpful. Cuz 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 that's not good, however, like the 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'm shot him. But pretty bad. Sorry.
Yeah, 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.33? V three?
Oh, actually. Hang on,
there's actually a question for Steven.
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 have an A at the end, I usually do. Di G and ama at the end just to like, make sure that it's like, you know what it's going to 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 takes you an extra two seconds, you know, 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 doing it, you know, you had he hand 10 projects to 10 hardware engineers, you're gonna get 10 Different schematics, and they're all gonna 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 it 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 did. Like I never wants to open a PCB program. Because of college. I did it on my own, you know. And so, you know, anything we did was just like whatever wires we had to do in our lab notes to get, you know, get I mean,
I can think of three different ways to draw a resistor. Yeah, this schematic right there's
a bunch of ways and it's different actually based off of you know, where you are in the world. You know, in the UK they draw resistors as a as a box as opposed to a squiggly line. And so, you know, there are some standard angle
squiggly line L I apologize squiggly line, isn't?
It Right? Line? It's, 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 is gonna be like we can talk about like, if you give us a project, like I'll use an EF maten. And then Stephen Beck, 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, like, I was using a transistor. So let's run with that, like an NPN bipolar transistor, the emitter has the arrow pointing out out of it, it should always point out, regardless of how big or small or weird you draw, 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 we should do that. And then make a shirt out of it. For the end then right Mac vibe engineering bug? Yes.
I actually didn't mean a standard for the components, because I guess I knew that that happened. And I've you
know, it sounds like less, 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 and wire patterns and how you
ensure individual companies together?
Yeah, individual companies will usually have like a document. Like for that, but no.
It's the same as yeah, there's no Yeah,
well, there's I mean, there, there are attempts to get us to start doing coding standards, and then people publish them, and people publish them and similar tools help us follow them.
Yeah. local variables are all lowercase global variables are all uppercase, bah, bah, bah, bah, bah, that sort of thing. Yeah. There's more and more standards, like actual legit standards for the stuff when you're talking about like defining footprints and packages. But even then people don't care. That's the thing about it's like, people just don't care about those standards. As much as we talk about them,
I would think I would make the argument that, that maybe they're not fully educated on them. And what I mean by that is like, a lot of people don't know that those standards exist, like when you're just doing an oh, five surface mount resistor. Like, do people know what IPC number document to go to? That tells them how to do that? I would, I would venture to guess nine times out of 10. They don't know what number that is, you know, don't get it from it starts with a seven. No, no, Digi key does not provide the layouts. And in fact, most of the 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, though, they'll give you pretty good guidelines,
either. I heard something about a standard library of parts from a few vendors.
Yeah, I think Digi key just started doing that with KY CAD. This is this is getting to that kind of mentality with I guess hardware engineers, because we're Stephen was talking about like wanting to learn how drivers worked in like, wanted to do it just to learn how to do it. And so it's his that's how I think hardware, a lot of hardware engineers are with packages and hardware is we don't trust like what other engineers do. Oh, no. Steven, if Steven gave me a footprint, I probably would not use it.
At other way around is probably true to exactly.
Tell me where people hurt you.
First, when we first started with electronics, and the first time you spin a board, and it won't work because you put a SRC wide package instead of a but you see yourself. No. Oh, I downloaded the package. You downloaded the footprint.
You got somebody else's library? Yeah, 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 compile it's a lot of money. Yeah. Right. So the old the only way to, you know, the thing is you, 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're right, is you just do it.
Yeah, I would say, because if you if 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 a whole forums devoted to that.
That was the point of the internet.
So I mean, entering these footprints is pain. And it's, it's not. It's tedious and boring. And
the most fun part, I actually enjoy it, my favorite part of the job is actually finding a new part me like, I get the right, 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 are got weird packages.
Yep. And, and you know, a lot of the standards for these IPC, you know, standards that 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 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, not for every board. I mean, Parker has his own library of like, resistors, that he always uses, I have mine. And and like those if 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, I my like, let's say it's an O 805 resistor, like the one that the package I designed is actually in between what a purely machine place footprint would be and what a like 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 ore you can 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 see where you're coming from, I really do because there's 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, I mean, I have everything I do, I've made myself.
That's not, that's not completely true. I mean, like, I will reuse all my footprints. It's not like
yours. Right? Are you? Yeah, no, I'm not. I'm not trying to argue I find it fascinating.
It's a very different mindset from especially. I mean, I am, I'm going to talk tonight about a library that in Python, and I don't think I really want to use this library, but I want to know about it. And
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, you're only piecing things together from other people's things. Yeah.
From Scratch,
is actually 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 and like, how does that thing work? Because I don't want to import something that it does something else, you know, okay.
I mean, I read the API about it. And I read a function or two, if I'm unclear on the API, but I trust the API's 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's because
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, 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 every on the schematics, we would pull up the datasheet, for that, we would pull up the footprint for that we would measure everything, we would double check everything, because you know, 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, you know, 20 boards, and all of them be bad because one footprint was off, or because, you know, one thing was off, if like, the cost offset was good enough for that.
See each tray, your own individual operating system based on things you've done before.
You say your company has like a 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 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, you know. So I think it's, it's unavoidable in a lot of ways.
I'm just, you have code reviews, you have detailed in depth code reviews of actual important information, and not just fluffy names and stuff. It's, 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, you know, we're making we're thrown 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, is that what happened with the the SSH bug that was a couple years back to go to bug? Is that the right one? I think it was the hard job. Someone
use a go to statement.
I think the heart hurt thing or plead. Yeah. That was that the SSH bug?
Sounds right.
Yeah, it's interesting. That was such a big thing at the time. And now it's like, Oh, no.
Heartbleed was SSL was in TLS. That's it. That's it.
Yep. 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, no, that's not good.
To look at it. There were three points.
Yeah. But it's, it's that same thing. You were like, you know, please, someone could just press compile on that one again. Well, and then update all the systems.
Yeah, that's everyone who was Yeah. systems that aren't updatable. Yes.
Well, and 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 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 could I wish I would have looked at my footprint and made sure that everything was right about it.
But if you use the standardized footprint, alright, so
I guess that's the question, Why aren't there standardized, that everyone agrees and is tested?
Why is there why is there not one standardized code? software code?
Well, we have only one operating systems.
Do we have the languages and we can't deviate from them while using them?
Well, I mean, you can use pipelines what 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 like you're mixing together and one fun. No
Is it Why isn't there a standard code like language, one language to use APR, although it's the same thing in the hardware world where some footprints are better at other things.
Other will and and I think it's also a little bit further than that. If you go look at the standards for even the most basic component, a resistor, even the the IPC standards will give you three separate footprints that you can pick from and there they relate to three different manufacturing capabilities. If you want to do XYZ manufacturing in China, then pick this one if you want to go into space and be super reliable, then pick this one that's gonna cost more, and things like that. So these The thing is like, it's never just default. It's never just like pick one, and you're good. I mean, it for the majority it is, but it's not always going to be that case.
Wow, I'm sorry.
I wasn't trying to be mean about No, no,
no, it sounds really, really good explanation. Yeah. Yeah. No, that that's.
So I wish it was that way. Okay, so I'll admit, 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 footprints are acceptable, like the soI C 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 gonna 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, you know, in a lot of cases, I will just rewrite that stuff.
And also using somebody else's, like, footprint, know that that footprint never looks like your footprints. So like, you have this and the text will be different. And it's like a, an okay, it's gonna be my style monsters. Yeah. It's like if you opened up someone else's code library, and they got a completely different style they use, they use tabs and said double space.
Those monsters?
I'm actually a tab guy. So.
Okay, so I accept that. I have a quick question for you. I actually thought about 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. Should 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 should never give the sales team an opportunity to change something? Because they will. It will
usually historically, there's a product team put 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 changes, right? So if it's a bug, you know, is it something where we're gonna have to rev the board? Is it something where we can do a firmware change? is a combination?
And it depends on Yeah, it also depends where it comes from? Is it that there is no longer flash of this size, or discolored time is 28 weeks. And so that definitely comes from hardware features for the user usually come from the software direction, because that's what they see who the product manager is complaining to. Because they think everything is software. I mean, there are system things you 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 it'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 to get me started.
And you triggered them pretty hard
to you. I mean, how is that the software engineers 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 to failure,
that there was actually another question I was going to ask. So let's just run with that real quick. If the 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 hardware engineer can do is to sit down and talk, figure out the differences of the datasheet themselves, which they have to do. And then tell me about the differences. asked me how long it will take, like, just in general terms, is this a week long project or six month long project? It doesn't. 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 and multiply it by yourself, or you don't have to ask myself, just multiply it out by how many hours that is, and how long it would take and, 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 1000 of something, in your sense spend, and you're saving five cents on it. And you're using 100 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 harbor engineer, why did you do that? Or no? Tacos, people,
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 he 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 that like, the only reason this changed was because someone got a good lunch out of this.
I mean, I would do argue that I got to get lunch,
because you're just changing the footprint. And I have to do all the work. Taking me out to lunch, at least two. Yeah,
it'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 spent an extra 20 seconds or an extra 20 minutes making someone else's life, an hour or two easier than you've, you've won, it's a team sport these days. And we're all individuals, but it's still sacks on the footprints, a team sport. And
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 you all would like to have final thoughts, closing arguments,
arguments, one more, one more. D bouncing a button firmware or software or hardware.
Oh, Parker's asked me this one before
a hardware because I'm lazy.
depends on the quantity fits more than 10,000 then I'll do it in firmware. But if it's less than 10,000 fire on capacitor.
I think the last time I answered this, I said both.
I implement I usually employ
suspenders.
Well, we talked about like FCC CE testing and stuff. Loss sensitive that way.
Yeah, I mean, it's 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.
Yeah, yeah, you know, okay, 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 firmware thing. But when you're at the gas pump, any gas pump, it doesn't matter. Pick any single one. Why are the computer so damn slow? Like, if I press a button, it should just go
You should hear Christopher's rant about point of sale systems and how
I think I'll answer it this way. lowest bidder.
Oh, yeah, yeah. Okay, that makes sense. Yeah, just make them a little bit faster like it's the only thing about making it slower the only thing that hurts is the guy who wants to go fast like everyone else could go slow if you want to.
They could sell more gas if they could put people through faster Yeah, yeah. Here we go.
See the new gas stations right they have screens that have like ads and stuff on Yes.
The yellow that's where all the computing power is coming video decoder Yeah.
Yeah. Not go into
the bucket. That's for sure. Ads buffer quickly. It's actually when you have to type in your zip code that takes forever.
Oh my god. And it's game over if you do that,
like you're used to when that happens. Just change pumps.
Yeah, no, I've done that. I've literally drip driven to another pump. Yeah, I think that's my closing argument there.
Yes. Well, this has been a crossover show of the macro fad podcast with Steven Craig and Parker Dillman, and the embedded FM podcast with me, Ely, co white and my co host, Christopher Wait. You can find both podcasts in your normal podcast app or look on their websites, macro fab.com under blog or embedded.fm, under embedded embedded.fm Thank you to Christopher for editing, as well as being my co host 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. 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.
Thank you. Yes, you are listener for downloading this show. If you have something that you want, Stephen and I talked about, send us a text at all the cables plugged out. Anyways, send us a Tweet at macro fab or send us an email at podcast@macro.com. Go check out our Slack channel. I'm trying to do this from memory because I don't have it written down. But I think that's all I need to talk about. Yeah, good. Later, everyone.
Is grinding out math problems just busy work? Is the current state of Math class curriculum hampering the real life deployment of engineering skills?
The engineering mind. Stephen and Parker discuss if the process engineers use to solve problems is inherent to engineers or is there something more?
Texas Instrument SOIC package oddities? Has Stephen unearthed some counterfeit components or is it just a new manufacturing process from TI?