Embedded - 480: Surprises Early In The Game

Episode Date: June 27, 2024

Jerry Twomey spoke with us about his new O’Reilly book Applied Embedded Electronics which covers embedded topics such as EMI, signal processing, control systems and non-ideal components. Jerry is also the principal engineer at Effective Electrons. His articles are linked from there and you can contact him via the site. Here is a 30-day trial for the O’Reilly Learning System. You can take a look at Jerry’s Applied Embedded Electronics and Elecia’s Making Embedded Systems as well as hundreds of other books about software, hardware, engineering, and origami.  Transcript

Hello, and welcome to Embedded. I am Alicia White, alongside Christopher White. Now, you may have heard that I have a book. It's called Making Embedded Systems, and I recently finished the second edition. It's a book that is for software engineers who want to get closer to the hardware, and hardware engineers who want to write better software. But what if it was written by an electrical engineer for electrical engineers? Well, then you'd have Applied Embedded Electronics.

Our guest this week is the author of that book, Jerry Toomey. Hi, Jerry. Welcome. Hello. Thank you for having me. Could you tell us about yourself as if we met at a conference? Okay. I'm an electrical engineer by education. I've spent about 50% of my career in the circuit systems and PCB world. And I spent about 50% of my career as an IC designer doing mostly analog mixed signal RF type design, uber high speed data for computer systems and things of that nature. Historically, I started off in Massachusetts, moved to San Jose, spent some time in Silicon Valley, and these days I'm down in San Diego.

Multi-sector activity of mine has been a little bit of everything in the electronics world, from defense projects to consumer electronics to enterprise computer systems and the electronics that go in them, RF systems and medical devices, and others. I've got about a 40-year career, so consequently I've been all over the electronics industry. That actually brings up a listener question. Timon asks, do you feel like the job of the EE has fundamentally changed over the past 10 to 20 years? Oh, it's radically changed since I got into the business. We've had a strong migration over the last 40 years from analog to digital, but in the last 20 years, we've had a stronger less aware of the electronics or the analog aspects of things and are a lot more aware of the digital things and the necessities

of coding things. All right. So we're going to talk more about that later and about your book, of course. But first, we want to do lightning round where we ask short questions and we want short answers. And if we're behaving ourselves, we won't ask how and why and what about bypass capacitors. Are you ready? Sure. Hardware or software? You need both. One's a brick without the other and the other one has nothing to run on. They're both important. Writing or training? They're kind of intertwined. I've done a lot of technical presentations, and I've written a ton of magazine articles, and as you know, I've recently finished a book.

What is the best part of Balboa Park? Hmm. That's an interesting question. I didn't expect that one. I'll say the model train museum. Oh, yeah. The devil's advocate. It's really cool. I expect that one. I'll say the Model Train Museum. Oh, yeah. The Devil's Advocate. It's really cool.

I love that part. Are extraordinary desserts extraordinary? No, they're fattening. I can tell you folks have been to San Diego a few times. Have you seen the Green Flash? Many times, including in the middle of the ocean, out of sight of land. So, yeah.

Do you have a favorite fictional robot? Um, actually two of them, uh, C-3PO and WALL-E and both for the same reason. Uh, there are two computers that in their depictions, in their movies, they show emotion. And emotion is going to be one of the most difficult things to do for robotics and AI. If you could teach a college course, what would you want to teach? Oh, wow. I've already taught a multiple number of college courses. Pick a favorite, then. Oh, I like the AZD DDA converter course.

I used to teach for UCSD. I've taught a course in phase lock loop design. I've taught a course on mixed signal IC design and medical electronics. I've enjoyed all of them for different reasons. I'll be honest with you, teaching graduate school at UCSD is kind of demanding because you can't gloss over anything for the grad students. They're going to nitpick you to death. I taught a course, and it wasn't for grad students. But still, it felt like every week was a quiz on every part of embedded systems. I never knew what they were going to ask. You can get taken to the cleaners that way, for sure. Yes. And I had to really becomeers that way for sure. Yes. And I, you know, I had to really become much better at explaining things. I felt like one of the best ways to learn a subject was

to have to teach the college kids or the equivalent. Anybody interested in the subject and suddenly they have all these questions and you're like, because... I can't answer, I don't know. And also I can't lie. Right. Okay. One last lightning round question. Do you have a tip everyone should know? When it comes to design or life? Pick one. When it comes to design, I would say try to get your design off the simulator early in the process

and try to get yourself onto the hardware and develop your code over on a hardware platform and don't obsess on the simulator. As for life, that one's easy. One of my favorite books is Dale Carnegie's How to Win Friends and Influence People. And a lot of engineering and science types could use better people skills. We all work in a village, so to speak. It's a smaller village than most people really expect to. This is true. Okay, so your book, Applied Embedded Electronics. Could you tell us about it?

Applied Embedded Electronics is about the circuits and the systems and the nitty-gritty of designing a hardware platform. There's many good books and a few bad ones, too, out not go into the nitty-gritty of all the electronic systems that attach to embedded systems to make them work, how to drive motors, how to put together a power supply, how to communicate things in challenging, noisy environments, and a multitude of others. Those are just a couple of examples. But the book goes, and it's not designed to compete with many of the embedded system books that you had a chain of where your data is and how to choose an ADC for an application. Sure. What do you think software engineers or new electrical engineers from college don't know about, oh God, now I have to choose between all of these chapters, about ADDs? Many, many of the books and magazine articles, et cetera, on embedded systems treat things as an ideal. They treat things as ideal ones and zeros, and we've perfectly captured a non-aliased data stream associated

with some analog signal. I think one of the biggest downfalls of a lot of new engineers is the fact that they don't understand the multitude of non-ideal issues that can come up and bite them. Everything from noise to linearity problems with A to Ds to aliasing due to out-of-band signals and things of that nature. And dynamic range, too. I remember shopping for systems and getting quotes for, oh, yeah, we have a 24-bit A to D, but the noise floor is way up here, so you have effectively 19 bits or something. There's all sorts of stuff like that. Right. And there's actually a section in my book on the subject of the effective number of bits, the bits that are actually real, and then you've got the ones that are lost in the't get told that things are non-ideal? Or do you think they have so much information and yet they still don't have the information to do an electrical engineering career?

It depends upon who's teaching them. I find that getting into the non-ideal aspect of electronics has a tendency to be lightly touched on in graduate school, but very something that's analog in nature, noise, ESD, whatever. And consequently, there's not as much of an emphasis on the analog side of things for many, many students these days. As you pointed out, so many things are becoming less, I mean, are becoming more packaged in hardware. Mm-hmm. And so there's a reason for that, but that still means we need people who can do both. Right. first chapter of my book is I discuss the whole idea of technical detail at the system level versus technical detail down at the chip level or down at the analog front end level, which is

frequently where, you know, as you know, a lot of people doing system on our chip designs, where there's a complete bundled analog front end, there's a sensor, there's an amplifier and an ADC and what comes out is a nice I2C or SPI type data stream. So those prepackaged devices have taken and put a lot of the analog inside the package and said, put some power on and here's your data stream. Yes. And as long as everything is perfect, it works fine. But should you create an antenna, things start going badly. Yeah. And it sounds like everybody had, we've all had some painful learning experiences there. So who did you write the book for? Did you have someone specific in mind or a group? Yes. We've got a situation where, let me give you a little bit of a history on it. I went off and became an independent consultant. So goodness, somewhere around 2005, I think,

somewhere back there, maybe even earlier. And one of the things I ended up getting was a lot of clientele that came in with, we don't know what's going on, we're having problems with this thing. And that led to me writing, oh, at least a dozen articles for Electronic Design Magazine, I think one or two for EDN, I think another one or two for Chip Design Magazine, where I described what the problem was that I had run into as a consultant and said, this is how you do this, folks. This is how you deal with noise. This is how you deal with ESD. This is how you do this, that, or the other thing. And consequently, all of those articles based upon client problems were what motivated the book. And I would say the best fit for this book, and this seems to be supported by a lot of the people that reviewed the book on LinkedIn, is that the designers that really appreciate it the most are people that are three to five years into the business. And they've made a

lot of the mistakes that they read about in the book about, you know, do this or you're going to have this problem. So it's kind of 40 years of condensed experience as a sort of a fast track start for people in the three to five years of industry experience kind of role. Yep. Yep. Exactly. And why do you write? I mean, you're a consultant. I assume you have that writing is partially advertisement, but there are other probably easier ways to advertise. Why do you write? I enjoy it. I've written all kinds of technical articles. I ghosted a book, oh goodness, a number of years back for a CEO that had to be out there publishing things but didn't have the time to do it. So this is really kind of my first official book, but I've actually been in a couple of other books as a ghost technical writer. But I enjoy the writing process. I find

that in the field of technology, there's an atrocious amount of stuff out there that is written in a manner that's not understandable or drives into areas where the end user doesn't need that information presented in that way. Engineers, many of them have trouble communicating things effectively. I think it's interesting that many of the consultants I know also write? And I haven't figured out if it's an egg or chicken thing. Do we become consultants so we also have time to pursue writing? Or do we start writing because we're consultants and need advertising? Or are they just two different things? I don't think the sequence of events is hardwired in one direction or the other. I do think that I personally went into consulting to get a little bit more freedom in what I was doing. I mean, I've worked for some really great companies

and done some really great products. But when you get out there as a consultant, you're allowed to do a lot more things that are different and you're allowed to be a little bit more fussy about what you take on, you know, as long as you can pay the bills, of course. And your consulting company name, Effective Electrons, where does that come from? It's a term kind of buried in the back of semiconductor theory. In addition to designing circuits and embedded systems and IC design and things like that, both when I was at IBM and Fairchild and actually at LSI Logic, all three of those companies, I helped bring up different semiconductor processes. I helped launch the RFC MOS process when I was part of IBM.

Consequently, I've been into the semiconductor theory of things. The name of Effective Electrons is about the electrons that are available in a dope semiconductor. And I just thought it was kind of a nerdy statement to sort of summarize my entity. Do you – a lot of the consultants I've talked to recently have gotten burnt out. Do you have any problems with that? I take on work when I want to take on work. I do things that I want to do. I generally don't try to maximize my income. My money situation is fine, so my consulting scenario means I can be fussy about what I do and I've got enough of a reputation,

mostly through the magazine articles and stuff, that I turn away interested parties on a very regular basis. Have you seen anybody come to you from the book? From the book? A couple questions through LinkedIn people, but not a company coming to me looking for help as of yet. The book's too new. I mean, let's face it. It was finalized right before Santa Claus this past year. And consequently, you've got to ask me that question in a year from now. Yeah, it does take a while.

And got to do some promotions. I'm starting to line up both IEEE speaking events and trade show speaking events. Are you going to them in person to do the talks? It'll be a mix. It depends on where it is and things like that. The stuff on the West Coast, I'll definitely just go to directly. I've got a couple of invites to talk at a couple of universities back in New England, and I'll probably set up a week in the fall where I go do all of those in one whack.

Visit some family and friends while I'm back there. Two birds, one stone. One of the chapters I particularly liked from your book was the EMI chapter, which I think is like five or six, probably six. It answered a lot of the questions that I've always not been able to adequately answer for clients about, okay, so what do we do when we say we're certifying our board? What does that mean? How do we fix it? How do we fix it in design?

How do we fix it in application? How many times have you had to provide that information before you decided, I'm just going to write it all? I've been brought into problems where they had EMI issues and they weren't passing FCC Part 15. That's happened a lot. In addition, all of the ESD testing and stuff that goes along with medical devices, again, I've had to deal with many clients on that. And consequently, initially, I wrote up things on noise for electronic design and ESD for electronic design. And then it got morphed into the book. ESD, when I started my career in the 90s, I mean, you looked at a board wrong and it had an ESD problem and exploded. Well,

not quite that far, but the boards have changed, right? Things have changed so that ESD is, I mean, I'm not going to go and shuffle my feet on the wall carpet and then, you know, touch my board. But it has changed, hasn't it? That's not my imagination. I would say I'm going to disagree and agree, and let me clarify what that means. I think that the mitigation of ESD has been a lot more systematic in the last 10 or 20 years. Prior to that, people didn't really understand what was going on that well, and they didn't understand what the fixes needed to be. Nowadays, if you consult with the right thing, my chapter on ESD speaks for itself, there's a systematic way of dealing with ESD that's pretty well understood and usually pretty successful. In one of your chapters about how GPIOs work, you showed that there were, I want to say

ESD catchers, but there were, GPIOs used to be wired to the processor, but now they go through pull-ups and pull-down gates. With diodes or something. That's always been there for... Oh, goodness, I'm going to go back. Heck. Remember the first processor that I had pull-ups on. ESD protection has been around for a good long time. I think the quality of it has improved some, but not recently. I would say that a lot of the progress on ESD was 30 years ago. We're all slinging around bare dev boards now, you know, piles on our desk and manhandling them. I remember carrying boards and making sure they were well wrapped before I left. I still do that. And now, like, I'll run up and down the stairs.

Well, all right. As long as I'm just holding it by the edges, I don't really care. I used to be so much more careful with ESD. Now it's got to be like a really fragile board for me to care. Well, in a development environment, I'm not going to be too fussy about it. In a manufacturing environment, you've got to be obsessive compulsive about it. Well, and dev boards are much cheaper now than they used to be. But like the nordic has this nrf 5340

that they ship half dressed um like only the top is enclosed and the bottom isn't and the buttons are on the bottom and so you're definitely getting close to things that i still am a little squeamish about getting close to well and you're telling me little squeamish about getting close to. And you're telling me it's been 30 years since I really had to worry about this? I haven't damaged anything with ESD. No, no, no. I'm saying a systematic approach to ESD on chips and to a lesser extent on boards has happened about, I would say, about 30 years ago, about 1990, maybe even a little earlier than that, where if people knew what they were doing and made the effort, you could set up a board to be handled with no pain, no problem. because of the large amount of capacitance associated with ESD protection and the high frequencies of a lot of RF front ends,

you can't really get as good an ESD protection on an RF input as you can on like a low frequency digital input because you just can't support the capacitance if you're trying to get a two and a half gigahertz signal off of an antenna. Oh, it's got a board antenna. Just don't touch it. Well, no. You're skipping over.

That's probably on the plastic side. You are skipping over the last week and a half that we spent trying to debug a piece of hardware that was probably damaged by ESD. But that is one that actually was going to be fragile because it was an analog something, something. And so that was always going to be, yeah. And it had some wiring issues in the beginning, so it might not have been ESD. Well, maybe. We could have blown that ship up so many ways. Sorry, Jerry, what do you think software engineers need to know about electronics?

Oh, wow. Yeah. That's a gear shift right there. We'll be back in a half an hour and see how you did. That's okay. What do software engineers know about electronics? What do new embedded systems engineers need to know about electronics? Oh, dear.

That's a really big question. Let's see. He would be sensible to just say, you should read my book. Well, I can definitely pimp the yours, Alicia, is an excellent starter for somebody that's dealing with the basics of embedded processors and things like that. And one of the things I do like about your first edition book, I haven't read the second edition book, but one of the things I did like a lot about the first edition of your book was the fact that you did not delve into specific processors that much. You kept it generic. And I thought that was a very good approach to it because of the fact that as soon as you write a book about a specific processor, and I don't care what it is, it's going to be obsolete by the time the book's been out on the shelf for a year or two. Oh, that processor doesn't exist anymore, or the things have changed.

So you kept it generic in a similar manner with my book. It's a situation where I'm not talking about specific processors. I'm not talking about specific processors I'm not talking about specific products it's about all the things that are necessary for any electronic product to be successfully implemented so did I answer the question on that one or not? It was such a global question, I'm not sure. What about the interactions between hardware and software? First, do you think they've gotten better over your career? code have become less aware

of the actual physical electronics. We've all used an ARM processor where nobody really digs down into the guts of what's going on inside

of an ARM processor. They just use the thing. It's going on inside of an ARM processor. They just use the thing. It's a 32-bit processor. You know what they're – or even – they have 64-bit ARMs now. Only for mobile computers. It's lots of 32-bit – it's mostly 32-bit processors. You're not really worried about floating-point math accuracy. You know what the clocking rate and the MIPS kind of information is. And beyond that, you treat it as a black box.

And a lot of designers nowadays treat the hardware as a black box. I think that's, yeah, I think that's probably true. I'm thinking about designs now and schematics that I read and just how little is on them beyond ICs with interconnections and maybe a bypass capacitor here and there. It no longer looks like electronics to me. They look like block diagrams. Is that a consequence of just so much stuff being integrated into ICs and they're just high-density modular things that you don't need a lot of support electronics for, or has something else changed? We've gone to system-on-a on a chip and the modular approach for sure.

When I was getting out of college, board level design was done with a bunch of bipolar transistors. Yeah. Okay. Nowadays, oh, what used to be 20 transistors on a board is now one-eighth or one-tenth of some analog front end that's got the whole shooting match from ADC to phase lock loop timing acquisition, you know, everything necessary to produce a synchronous data stream. And you go from there.

Even the processors don't require as much periphery now just in terms of like crystals and supply voltages and all that stuff. And they have onboard clocks, onboard flash RAM, ADCs. I mean, they have system on a chip? Yeah. It's all there. Oh, sure.

I mean, I've used my fair share of things like Atmel processors and stuff like that where you basically pick something. Okay, it's got suitable ADCs. It's got suitable clock synthesis. We've got counter timers that we need and go from there. You definitely treat it as a box. particular chapter is we want to design control loops that are pretty much all digital. Everything except for the ADC on the sensor and the DAC on the control side, but everything else is digital. And that's extremely reliable. It's extremely predictable. And it's what I'm a big proponent of. And I'm old school analog from way back when.

But I know the promise of digital stuff when I can get the A to D converter and the D to A converter for $1.50 each or less or it's just embedded in the controller chip. That's a good way to go. All you have to do is put on the low pass filter and everything's golden. Well, yeah, kind of. Aliasing is another whole thought. It's actually something I would like to add a little bit more on the subject of filtering in second edition of this book. But that's downstream. Are you looking forward to doing a second edition we'll see um i took my time on this one you know i'm i'm at about 600 pages so i i wrote about

most of the things that i thought were important um i the one thing i i would like to do uh in a second edition of this book relative to the material that's all been covered is what I'm going to call more quantitative examples. I talk about a lot of concepts, but one of the things I always find when I'm teaching a topic is it's always good to teach the concepts but then show a problem that's been worked out end to end, from concept to finish and all the details in between. And a lot of people will use that as a useful learning tool. In my chapter two, which was kind of funny because it was very similar to yours, I try to convince people to diagram their systems. And I give them different diagram methods and blah, blah, blah. But just a system diagram of how it should all go together. And you give examples of them.

You give several examples of what they would look like. And it was really interesting to see the difference between here are some pretty simplified but still complex examples from your book, where I have this very simple example because I'm trying to get you to build it. And so I have to go simple, simple, simple. And even at the end, it's not nearly as complicated as yours, but yours was a better example of how a system really looks when you take in its whole complexity and not just baby steps that I was providing. Possibly so.

I can't judge because I'd have to go back and look at your examples. Are they the same set of examples as in the first edition, as in the second edition? Were they new to the second? No, no, it's the same set of examples as in the first edition, as in the second edition? Were they new to the second? No, no, it's the same basic stuff. The second edition has a different diagram type and some other examples, but it's still very much, if you're building a system, build up a diagram first. And if you are new to a system, try to figure out the system using a

diagram. Don't just try to figure out the whole system right away, just steps. But I liked your diagrams because they were more complete. So I like this idea of being able to give more examples and more quantitative information. O'Reilly strongly encouraged me to have a GitHub repo. They didn't do that for you. I had the offer of that sort of thing and I said, well, this is not a software book. Right. And, you know, I have a chapter in here on coding and software issues, but one of the things I say on the front page of that is this is not a coding book, and I am not a coding expert. I mean, hell, I've programmed PDP-11s from the front panel, okay?

And if that isn't the dark ages of computers, I don't know what is. But I'm not a coder. I'm not a software person. One of the things I did actually when I wrote that chapter is I had a couple of friends of mine who have spent their life writing code for Apple and a zillion other places. And I said, look, guys, I want you to read and review this and fling stones, feel free. Because it's an area that I've got some working knowledge in, but I'm not an authority on software. And I would never pretend to be. I have a little bit of software in my repo, but I also have a lot of links to other things. But also I have a few calculators.

And I think you talked about it in one of yours, the low power section, battery section. Where you need to go through and figure out what the average consumption, average current consumption is. And you can do that either by measuring things and you have to do that in different states or you can do it by building it up from the data sheets. And still you have to think about the different states. If you're in sleep state, you have this much. And so how long will your batteries last?

And so in my repo, I have a couple of worksheets. And I'm so happy with that. Because like what you were saying, where you need calculated examples, this gave me a way to say, look, I have a calculated example. I can't put it in the book because it would take 400 pages. But go look there. You can type in your own numbers. Then you can copy it and make your own thing. Do you have a way to do that? And the cellular designs tend to be heavily, heavily defined as an entire end-to-end software device and modeled. And that includes a development of models of power systems and battery life and things of that nature.

And if you've got the resources, the manpower, and the time to do all of that, that's great. But if you're trying to get a product out the door quickly, I think that doing an estimate on paper is a reasonable starting place. From there, you can – so you get two extremes, figure it out on paper, manual estimations, or do a full-end simulation of the thing end-to-end where you can pull power consumption numbers out of something else. One takes time to execute, probably a bit more accurate. The other one tends to be a little bit more depends upon the skills of the person making the estimates. I want to ask, changing subjects a little bit, ask some more detailed

questions about your book in particular. One of the things that was interesting is you have a whole section on spacecraft electronics. Sure. First of all, could you describe how spacecraft are a unique challenge, but also what made you decide that that was something that you wanted to focus on or at least touch on? Well, one of the things I think – I'm pretty sure it's mentioned in the book – is in the special systems section, the systems that I write about are systems that I've actually been involved with. I've done stuff for satellites. I've done stuff for both LEO satellites and for geostationary satellites. I've done medical devices and are on the list there. So consequently, the reason I picked and did something on that topic was I had hands-on knowledge in that area and could consequently comment fairly intelligently on it.

The challenges for satellite stuff is kind of interesting. Let me think. What is it? There's four different things that are important in satellites, okay? You've got to account for vibration and shock, mostly due to launch situations. There was a ton of CubeSat stuff that died because it never came live up in the air because of the fact that people did the design with a consumer electronics mentality and they hadn't accounted for the vibration shock of launch. And it was broken once there. So there's vibration and shock. The next one is vacuum. Satellites are not pressurized.

I think Sputnik was pressurized, but everything after that, no way. They do not pressurize that stuff. That would add a lot of cost and weight to mainstay. So you've got to have electronics that'll work in a vacuum. That's something that doesn't, I guess, capacitors would be a big thing. Oh, yeah. Yeah. Oh, yeah. And because the typical electrolytic capacitor will just blow up in a vacuum. And sometimes not in a vacuum. Yeah, this is true too. I'm not a fan of electrolytic capacitors, and there are ways around them if you're clever.

So you've got the vibration and shock. You've got vacuum. You've got radiation hardening. Radiation hardening is kind of a nasty can of worms because no one thing solves radiation hardening. It has to be a mixture of a radiation hardened semiconductor process plus shielding plus physical placement layout, and a bunch of other things. So radiation hardening can get to be a little bit of a gnarly problem to solve. And lastly, in know, in direct sunlight, indirect sunlight, not indirect sunlight, close in, you know, Earth orbit or closer or way the heck out there, you know, past the gas giants where you can't rely on solar power and, you know, very cold or very hot. So that's got some challenges to it, to say the least. I think people have misconceptions about space, too. Oh, space is cold. No, space is terrible at transferring heat. It's a very different problem. The funny thing is, the first time somebody does electronics for a satellite, they start thinking about heat sinks and stuff like that. And I go, it's all conduction.

Yeah. There is, in a vacuum, there really is no temperature. Right. And it's a different way of thinking. But there has been, well, I guess it was a few years ago that Planet Labs and a few other folks were doing consumer grade electronic disposable satellites. The key word is disposable, right? Yeah, well, here's the thing.

The things I'm talking about are this type of things that have to be in there for any satellite to work. And if you can't make it through the launch, vibration, and shock, you're dead. If you've got something in a vacuum and the components are blowing up because they can't deal with a vacuum, you're dead. Radiation hardening, again, you can't turn the radiation off. Sorry. Just like on thermal extremes, you a distributed grid – distributed network. It's not distributed grid. Distributed network internet communication via LEO satellites.

All of those things have got to have the capability to deal with all of those. Now, the good news is you can generally get the cost of a satellite down in mass production methods. There's a lot of geostationary satellites that were done as one-offs, and that's expensive, as we all know, whereas producing 100 of the same thing, much cheaper. This makes me more impressed by Voyager, which they've recently fixed again, and it's still out there doing stuff. Yeah, I actually know somebody that was involved with that. He's kind of retired now, but we had some interesting conversations on email. When you started your career or when you started using watchdogs for processors, did you kick them or pet them from the very beginning? Oh, my. Well, first of all, you don't want to get in trouble with PETA, you know, ethical treatment of animals. So you don't want to be talking about kicking dogs.

Okay. I am all in favor of petting or feeding the watchdogs now. Yes. Okay. But I did initially use the other terminology because that was what I was taught. It's already in the code. Yeah. I just didn't ever think about it because it wasn't, but yes. And so I wondered if you had that same epiphany of, oh, my God, what did I just type? No, I was kind of aware of all of that stuff. I'm trying to think who made me aware of all – probably one of the management training courses I had when I was at IBM. They were really good at teaching you how to be politically correct when they were putting you up in management. So,

I was kind of already aware of that stuff. But yeah, you don't want to be kicking dogs. It's kind of like, okay, what is it? Master-slave circuits. Did O'Reilly get it on your case relative to can't use the words master and slave? Yes, although I had already written the this is what what we used to call it, and that's why

it's Miso and Mosey, and this is what we're going to call it in the future, and just suck it up and deal with it, folks. So did you, I ended up with, I wanted the first character, I think I ended up using manager and subordinate. I used micro and sensor. Okay. It's not always a sensor, but it was. What was the other one that's been used?

Controller and. Peripheral. Peripheral and controller, which is kind of muddy sometimes. Yeah. The reason I like manager and subordinate is I wanted the M&Ss for that. And manager and subordinate fixed that such that all the acronyms could remain the same. Yeah. Yeah, it was important to me that the acronyms remain the same, although SDI.

Serial data out? Yes. Serial data out. That's what it is. Sure. It's not. Well, that's. Censored data out. I don, that's... Censored data.

I don't think it was ever slave data. Well, but on the chip we were just using, that I won't mention for reasons, the serial audio interface has SDI and SDO, and that has not changed whether it's in charge or not in charge. That's true. I think those are slated as serial for their labeling. A question from Andre, who has purchased your book and is enjoying it. What are your recommendations for folks to improve electronics design skills?

And do you have different recommendations for beginners versus experienced professionals? Oh, wow. Interesting question. Let's go with beginners first. I would say that for beginners, they need to learn the ideal systems first. Going to your book for embedded systems, great way of learning the ideal systems, because you deal with things mostly as a, this is how it's supposed to work. Where, and after you get out there with the basics on this

is how it's supposed to work, um, at some point you're going to start running into the, oh, but it doesn't work that way in the real world. And that's when you want to start looking at the book I wrote because of the fact it's all about things not being ideal. You know, it's not all ones and zeros when you got noise on it. It's not nicely lined up with the clock because of the fact that there's all kinds of latency in the system, you know, things like that. Funny, that reminds me of the progression of like physics education. Yeah. Because undergraduate, you start out and like, well, here's these equations and everything's

ideal and it's kind of a spherical chicken and whatever. And then you start peeling off the layers of idealness the further you go until when you're in grad school, it's like, okay, we don't,'t you know here's this thing and we can't actually solve this analytically and you have to do this numerically and there's all these problems and here's what happens when you know quantum mechanics starts biting you and um and that gets worse and worse and i think i think in in practical technical education that's not a not the the path, maybe the way the path works by default, but maybe it shouldn't. It's easy to get distracted by the non-ideal stuff and then kind of lose hope because there's so much depth to everything. I worry since it's your, I don't know, since you're looking for a career or a job, that people get surprised when they...

Have to keep learning. Well, not that they have to keep learning, but I was taught this. You know, why are you doing this? Oh, because it doesn't actually work that way. Which can be a bit of a shock. There's a lot of that. But the thing I tell the engineers on a learning curve, I say, is it's always good to glom onto people that can help you and have different insights. You know, it's kind of like I'm the first person to grab somebody that knows software and coding and say, is this viable? Can

we do this? Because it's not my field of expertise. And one of the things that's important about any engineer, in my opinion, is to understand what their limitations are and their willingness to address that limitation by consulting with others with expertise that are that's pertinent to what they're doing that's a good that's a really good attitude because uh you know the number of times we've had to fix things in software because somebody figured you could just fix it in software without asking um this high yeah this well we've all done the duct tape thing where it's, you know, oh, this signal is glitching and it transitions and you basically go, okay, we'll fix that in software by polling the

port 20 times and making sure that, you know, it's settled out kind of thinking. So you end up putting band-aids on all products. It's one of the reasons I try to avoid buying first-generation products is because I know all the duct tape that goes into a first-generation product. First-generation processors are the ones that I want to avoid forever. How about zeroth generation processors? How do you like those? I'm sorry. You're always fighting the last battle. I think that your point of admitting when you don't know something is something we forget to do, and it is very useful.

Well, yeah, and I think the people that claim to know everything are usually pretty fresh out of school. And for experienced professionals, do you have recommendations for improving our education? Continuing education. Where? Yeah, yeah. Well, yeah. Depends upon if you're self-motivated

for self-education and read books on your own or you like to take classes. There's plenty of options in the self-education world. Nowadays, for a lot of people, oh, let's go to YouTube, and I'm sure there's an answer there. Difficult to pick the chaff from there. But there are good channels, like Z Frank.

Wait, no. Lots of chaff, definitely. What do you do for yourself? With respect to? Continuing education, yeah. You know, I've kind of gone from being the student, in electronics anyhow, I've gone from being the student to the teacher in a lot of it. I think since my second job out of college, I was a technical lead on the program, and it's kind of been that all the way since then.

But I try to read new books. I'm obviously on the trade magazine publications all the time to find out about the newest, latest, and greatest. But I would say it's stay curious and keep learning. There's other fields that I go on. Definitely, I consult with other people that are much more knowledgeable. It's like one of the things I do, one of my fun things in life is I race sailboats. And down here in San Diego, we've got an incredibly skilled number of people in sailboat racing that I've learned an incredible amount from. Sometimes you're the

master and sometimes you're the student. In the world of electronics, I tend to be the master if it's not the digital things, if it's not the coding things. On other topics, I definitely embrace being the student. I like to learn. I always like to learn. I've generally found that things you learn may seem pointless at the time, but even the practice of learning is good to maintain. And nothing is ever truly wasted. If nothing else, you can use it when you compete on Jeopardy in a few years, right?

Have you ever been tempted? I've actually been tempted, but I don't have the geography and the history knowledge that I would need. I don't have the pop culture. It's always been really embarrassing. I never had the pop culture for any sort of quiz show. Wait a minute. Weren't you almost done it? As a teenager, yeah.

Oh, okay. I was going to Jeopardy tryouts the second pass when my brother got hurt. I didn't get to go. And I still hold him responsible for me not winning. No, that's not true. I realize now I wouldn't. I didn't. I really didn't then.

And I still don't have pop culture well enough down that I could have. It's really embarrassing when you miss questions about like the Rolling Stones. You're like, I don't even know who that is. Oh boy. That was a quiz bowl. It was high school. It was really embarrassing. Well.

Okay. So what is the animal on the cover of your book? The animal, the, the animal, yeah, is a, uh, everybody says it's a kangaroo, but it's a yellow tailed rock wallaby. They're both marsupials. Um, they're both from down under in Oz. Uh, but it's a, a yellow footed rock wallaby is a little bit smaller than a regular kangaroo. And did you have any choice in your animal? They gave me a bird or a fish initially, and I said no. And I fed them back. I said, look, we're creating something new here. How about some pandas or

some other animal with its children? They came back with the wallaby with the joey in the pouch, and I said, I'm in love. Thank you. I'll deal with that. I can live with that. I wanted a dinosaur or a microbe. Okay. And they were just like, no. And they said, well, we have Michael Barr's book. And I said, that's a tick. No, absolutely not. Absolutely not. And so I admit that I love my night jar. If you're happy with what you got, you're happy with what you got. It's that simple. Yeah. I have a gray-eared nightjar, and it's got its floofy little ears that make it look like the serious expression is very fleeting, which is about right for my book.

And now you've got a color version for the second edition. I do, and I like it. Before we let you go, I want to ask if there's a section of your book that you're particularly proud of and you want to make sure that people definitely read. There's a number of different places in the book where I introduce material that is not out there in common usage, but it was buried in journal articles or things like that. And those are kind of in the ESD EMI section and also the control system section. Because the controls section, and I've done a lot of control systems, so the control section is something I said, I can't find this approach anywhere. I can find parts and pieces of it in journals. I can find parts and pieces of it in a couple of specialty books, the type of book that sells maybe six copies, and three of them were to mom, dad, and the kids. And the other three sold something really specialized.

It was out there. But what I did with the control systems thing was I set up something where I said I'm going to define and teach people how to do control systems, and they don't have to be a five-star math nerd. And consequently, how I teach control systems in this book is it's simple, it's graphic, and the parts and pieces of it are backed up by various journal articles and things of that nature. But the overall approach to it is pretty unique to this book. And I'm pretty happy with it because I've run into a lot of screwed up control systems over the years, and you'd be amazed at the number of people that don't know how to set up a control system, and they're doing it in industrial control systems all the time, and they're just sort of blindedly turning the knob until it works. You have a lot in this chapter. I mean, there's a little bit of state machines, but mostly it's... But does it have Bode plots? No. Thank God.

But it did have a transfer function. That's fine. It does have Bode plots. Oh, I'm sorry. You know, I got to read a lot of your book, but this chapter I did not, and now I'm really sad. Control systems is one of those things that, yeah, it's super important and it can be taught in so many different wrong ways. And I think I got taught in three different wrong ways before. I'm not sure I've ever been taught the right way, actually.

You should read this chapter. Read the chapter. I'm going to read that. PID doesn't come in until the last third, but that's because PID is usually a hammer that you don't need until you're doing something marginally complicated. And yet everybody just uses that on everything. PID controllers, you don't need a PID controller. Most of the times you need a PI controller, proportional integral. And that usually gets it done for 90% of the world.

The one thing that's a little bit ugly is the fact that everybody's heard of Ziegler-Nichols tuning for control systems. Yes, I understand that sigh. Because Ziegler-Nichols tuning is not the way to tune a PID system unless you want to sit marginally on the edge of stability. And why would you want that? Because when you do the manufacturing, they're not all going to be the same.

You want something that's really stable. Living on the edge. You got to tighten everything down. I don't know not all going to be the same. You want something that's really stable. Living on the edge. You've got to tighten everything down. I don't know. Well, here's the thing. Where's all the variance if it's a digital control loop? Where's all the variance in the system? In the sensors.

In the temperature effects from the sensors. In the noise. I would say that that's part of it uh but i i would also say that the device under control is um probably the thing that varies the most in in most uh control systems especially if it's something mechanical yeah yeah okay i i i yes i i agree i just Yeah. Yeah. Okay. Yes, I agree. I just tend to blame everything on the sensors because that's the part I can see more. It's probably the thing you've had the most trouble with then too. Yeah, of course.

I think we do tend to be input focused a lot because, yeah. The output's the output. Yeah. Got to do whatever it's going to do. Well, Jerry, it's been really great to talk to you. Do you have any thoughts you'd like to leave us with? Well, for designers, I would say take a look and read the book. It's available on Amazon, Applied Embedded Electronics, and it's subtitled Design Essentials for Robust Systems. And I think that the subtitle is just as important as the primary title because of the fact that these are things that are necessary to make a system reliable of the book. The thing I'll say to most designers is I'll say,

try to get yourself hands-on early in the design cycle and get off the simulator. I'm a big fan of simulators when it comes to semiconductor development. You got to live on a simulator to design chips. But when it comes to board level and system level design, I say, please get onto the hardware as soon as you can. I think that's always a smart course of action because then you'll have the surprises early in the game rather than late in the game. Our guest has been Jerry Toomey, principal engineer at Effective Electrons and author of Applied Embedded Electronics. You can find a link to his book in the show notes,

as well as a 30-day link to the O'Reilly Online Learning, which should give you enough time to check out his book and mine, and then you can decide if you want to buy them in paper or electronic. I'm not fussy. Thanks, Terry. It was good to talk to you. Good talking with you folks as well. Thanks for having me. Thank you to Christopher for producing and co-hosting. Thank you to our Patreon listeners Slack group for questions. And thank you for listening. You can always contact us at show at embedded.fm or hit the

contact link on embedded.fm. And now a quote to leave you with from Ada Lovelace, that brain of mine is something more than merely mortal, as time will show.