Electrical engineers are increasingly tasked with firmware and even software design—and it turns out it may be with pretty good reason. Are EEs ready?
Welcome to the age of coding. Hardware design has changed a lot in recent years, in no small part because electrical engineers are increasingly required to take part in firmware and software design.
In this episode of Moore's Lobby, host Dave Finch talks to two engineers about how their mega-companies rely on coding skills to make the best products possible.
A Big Thank You to This Episode's Sponsors
Meet Our Guests
These are the voices you'll hear in this week's episode:
Executive Vice President and Chief R&D Officer at iRobot
Microcontroller Applications Manager, Americas at STMicroelectronics
First, you'll hear Tim Saeger—Executive Vice President and Chief R&D Officer at iRobot—explain the importance of software development in robotics applications. You'll learn how software and hardware development can function within teams of engineers, what technology Roombas borrow from the cellphone industry, and what Tim considers the appeal of working in the consumer space.
Then you'll dive into the details with Sean Newton—Microcontroller Applications Manager, Americas at STMicroelectronics—as he and Dave talk shop about the use of control algorithms for MCUs and motor control applications. You'll get perspective on why embedded control is on the rise, how engineers can focus on developing their firmware chops, and how EEs can bridge the gap between analog and digital design.
Annotated Transcript for: "The Future Is Coding: The Firmware and Software of Hardware Design"
What's a fatal mistake that you see way too often?
I've seen many big-name OEMs try to come through at the last minute and say, "I want to launch my product in six weeks." And that's great but you realize you're basically in for a re-architecture of your whole design.
From EETech Media, this is Moore's Lobby where engineers gather to talk all about circuits. I'm Dave Finch.
Today we'll look at firmware proficiency and what that means for the hardware engineer.
Embedded computing and control have become ubiquitous features in modern electronics. Nowadays, even the equipment that blends our margaritas at the entry-level runs some version of firmware, and it's not surprising. The BOM costs introduced by fitting a circuit with embedded control capabilities are almost negligible when you consider the features and performance it affords you.
In some cases, adding compute capability actually enables an engineer to completely reimagine a system and substantially lower its overall production cost.
Thinking back to the margaritas, an AC universal motor control circuit is achievable at minimal cost using a simple thyristor and some passive components. But what if we consider a sensorless DC chopper drive, built on an inexpensive 8-bit microcontroller, a simple output stage, and some MOSFETs? The resultant gains in efficiency may enable you to reduce the physical size of your motor and the surface area necessary for proper thermal management. And, with some clever engineering, maybe the PID controller can operate well enough without a Hall effect sensor, which also helps to reduce system cost.
You'll offer better performance and more options to the consumer. All it takes is a little firmware savvy.
Of course, not every hardware engineer wants to be a programmer, which begs the question—do we even have the option of not being proficient in firmware and software development? At least to some degree.
Today we're visited by two engineers who have complementing perspectives on the convergence of hardware and software design, and what that implies to the engineer.
Sean Newton, Microcontroller Applications Manager at STMicroelectronics, shares today's landscape of novel embedded adoption.
Sean Newton clip:
There's a lot of new techniques coming out that help smooth that digital control, and actually give you an advantage over what we've had in analog control in the past.
But first, Tim Saeger is executive vice president and chief research and development officer at iRobot, the company redefining floor and lawn care.
Tim Saeger, iRobot (2:46)
While I've been off in the weeds re-imagining the perfect margarita blender, Tim has been working hard to create a world-class and scalable robotics platform for consumer vacuums, mops, lawnmowers, and, frankly, who knows what else.
His engineers' mission? To deliver the best in hardware, and—you guessed it—firmware.
The Intersection of Robotics and Firmware (3:15)
Tim, how many electronic design engineers are employed right now at iRobot?
I'd say probably in the 30s, something like that. Robotics—you've mentioned this, Dave—it's multidisciplinary, but EE's a big part of it.
And this must be some team, because robotics combines so many different elements, whether its positional awareness, sensing, motion control, autonomy. Very sophisticated hardware challenges. And I would imagine that all of this requires a very carefully architected and designed firmware, as well.
That's totally right. My background personally is EE, and I'll call it my distant training. And I have an appreciation for the fact that the stuff that we're doing, because it's consumer, it has to be cost-effective. But this is a super technical product because it is high-speed digital, there's a bunch of analog in it. RF. All of it is under software control, sort of at the different layers that we have.
It's super interesting, but it's also super technically challenging. And what most people don't realize is because, to them, I'll say it's a vacuum cleaner—but there's so much intelligence embedded in this thing that's at every layer from the hardware all the way through the software. It's just super interesting, technically.
It really is. And especially the challenges you're trying to overcome. You need to make this simple enough for the user and foolproof, but inside the device, you're dealing with things like motors turning on and off. You're dealing with RF, you're dealing with power supplies on the charging side of things.
There's a lot of things that can go wrong when you're introducing that many variables, that much noise in such a compact little form factor.
Oh, for sure. And there's all the compliance stuff that has to happen. The power efficiency, all the different things. It's just challenging.
So the team that we have is actually quite skilled. Because all the things that you described—it has to show up in a way that just works. This is what you need for a consumer product. It just has to work and be easy to use. And all that stuff has just really strong technology and architecture and design practices underneath it.
The Value of EEs Who Are "Software Literate" (5:13)
Of your engineers, what percentage would you say have significant experience with firmware development?
The organization is really... I'll say, strong. It's a strong technical organization, anyway, I would say, because of the disciplines in the work that we do.
Most of the organization is software at this point, I'll say broadly. In the EE team, I think there's a fair number of them that are also I'll call them "software literate". In the context of the work that we do, almost everything is under some form of software integration and control.
There are some very specialized practices that show up under software control higher up in the stack, but we've got RF capability in the organization that manages all the design. We've got all the circuit design and layout work that happens typically internally for us.
A lot of that shows up under software control eventually, but a lot of it shows up under firmware control and with integration, because of the stuff that you described. You're controlling physical things, you're integrating sensors.
You need to actually be able to have reliable communications, and all that stuff happens through firmware, typically.
Yeah. I'm thinking about some of the hardware engineers I know who have become pretty strong coders over the years, whether it was out of necessity, personal aspiration, whatever. Now, there's the ability to understand and write firmware, and then there's being a highly specialized software developer.
Do you find that your contributors are equally capable hardware and software developers or are there say pockets of specialization throughout the team?
We actually have, even for the firmware, I'll say we've got specialized teams in the software group because the production code is so complex that we felt like it was better overall from the quality of software point of view, to have specialized software people that are really responsible for in software products, if you will.
But there's a very tight coupling in with the hardware team, the double-E team, and many of those engineers also have the ability to program, right? They can, it's just that that's not their discipline per se. And so it's easier for them, especially when you're thinking about prototyping or even just trying to debug a circuit, you really need to be able to work through the software.
And from our point of view, that's at least a really strong benefit for them, even if they're not either asked or able from a functional discipline point of view to write production code. There's just so much in that architecturally, especially when you've got such a complex, real-time environment that the timing's important.
The code architecture is important to make everything run correctly. And so we felt like it was best overall to have specialized software teams for that, just working very, very closely with the EE design teams.
Absolutely. And I like it. If I were to take now the perspective of, say, the software engineer—certainly they are aware that the board needs to be laid out in a way that's very RF-robust. But they wouldn't have the years or decades of experience that a PCB layout design engineer might have in saying, "Well, we know that these have to be one mil traces and here's how we're going to..."
Yeah, exactly. And it's similar. And quite honestly, one of the things that I think is actually a strong skill and I value it a lot actually in some of the teams that are doing advanced development work, for example.
You want people who are sort of switch hitters that can do a bit of both, especially when you're doing prototyping work, you're doing early-stage quick and dirty. You want to see if something works, you want to test out some kind of application. It's really just super helpful if you don't have to worry about the production elements of the software and sort of the hardness of it. To just have a person or a small team that can go back and forth.
And it's the same, like you were saying, Dave. If you don't have to worry about the radiation characteristics of your circuit design, you can have people that can go back and forth and dabble in both and still figure out how to put something together, and really check out what it's doing. That's really what they're trying to do with that stage.
Staying on the Bleeding Edge: Borrowing Technologies from Other Industries (9:16)
So as a VP of engineering and as a chief officer, what are some of the imperatives that are on your desk nowadays? Is your mind on investigating new technologies, honing various hardware and software architectures, or do you have to be looking at things at a higher elevation?
Right. That's a great question, Dave. So our products, our audience... I think your audience would what I'm sure understand is they're so high tech.
The edge that we're trying to push as an organization—iRobot is a premium brand and the value that we try to offer through our products, much of it is built on technology, ultimately. And so we really feel like we've got to be near the leading edge of technology.
And the physical platform, the electronics attached to it, have to enable now what I think is actually world-class software.
The robots that we're shipping now, have a vision-based navigation system. So we're using technology that often is heavily either linked to, or we're writing the cell phone industry. Just the kinds of compute that we put into these products now is growing dramatically. And being able to do that quickly, leverage third party, whether it's open-source software or leverage other industries' componentry, to try to get it in place quickly and then have it sort of integrated.
The real value that I think we offer as a company, it has to be directed at a consumer problem, but it's really the integration. It's what robotics is, is you're integrating things and technology. We don't have to invent everything, but it has to come together and point at exactly the right way.
And so, for us, figuring out how to lead in technology and assemble this into a system that just works for people all the way back to one of the things you were saying earlier, it just has to work.
Nobody needs to care that it's a vision-based navigation system where all the stuff is underneath the hood. But man, getting all that to work well together and doing it quickly and basically trying to out-engineer the rest of the world, all the competitors that we have. Yeah, that's very much on my mind—very, very much on my mind.
And this is one of the challenges of working with this part of the industry, is you really have to have a long technology horizon.
It's also one of the reasons, quite honestly, that we're trying to use other industry applications where it's appropriate for us. So the cell phone industry is a natural one, because of the progression of technology and cameras and optics in that class of products, the compute in that as well, too. And a lot of the technology in cell phones is actually applicable to the things that we do in robotics as well.
See, now that's interesting to me, that crossover or maybe convergence is the right word? How are you adapting, for example, cell phone technology for your devices at iRobot?
Mm-hmm (affirmative). Yeah, so it starts with the chipset, the core computing engine in it.
We also integrate a version of Linux as the core compute platform for the product. And that actually opens up a quite a bit of technology that we can then integrate. Some of it is direct integration from the suppliers and software could be software components, but it also helps us choose Wi-Fi radios and other off-the-shelf commercial components that could come from the cell phone industry as well, too.
So anywhere we can get access to that supply chain, and either customize it or integrate it, it's just a real win for us, because that also is super high volume, and it's a way for us to gain leverage.
Yep. I can totally see the point now, that you were making earlier about. Yeah, you need engineers who can think and design at the system level, take all these different blocks, integrate them and make them work seamlessly. That's really the key.
Oh, totally. It's interesting. In my own background, I tend to think of myself as a systems-oriented thinker.
And I think it's one of the reasons I'm attracted to robotics, because it literally is... There's been some of the elements of our product, you've got everything from the physical, all the way down to charging systems and motor control, and other kinds of sensors to optics. You've got high-speed digital electronics, image processing, every type of firmware you could imagine. And then all the way up to in the robot applications that control how it navigates in the home.
I mean, it really is a very complex and interesting system. And so people... And one of the things I value in my team is, people who can hold significant parts of that in their head, and they can understand how it all works. And those people can live in our hardware teams and our EE teams. They can live in our systems engineering groups as well, too. They can also, of course, live in our software teams.
But it is so valuable to be able to hold big chunks of that system in your head, and then you have an ability to help architect the robot in ways that's really effective.
What Makes for Really Well-Designed Firmware? (14:13)
And architecture, of course, is a much different proposition than design. What makes for really well-designed firmware?
Yeah, it's interesting. I think I would start with the fact of the scale and the robustness that we try to operate at.
One of the things that we're trying to do in the organization is have a world-class software engineering team. And in our particular application, that's a little unusual, because most companies, when they think of software or software engineering groups, usually it's pure software. And when you're trying to develop firmware and you're trying to actually develop a realtime application that's running on consumer-grade hardware, that's challenging.
And to have it be done in an effective software engineering-oriented way, that's not something that a lot of companies know how to do well, as I've experienced it and when I talk to people in the industry.
So what we're actually trying to do is import the best of what I'll call pure software development practices and techniques, but apply them to world-class hardware design. Because to get the pace that we need, and the quality of the hardware architectures, it has to be integrated well with software engineering practices.
But most modern software companies are really just pure software. They're not doing the kind of system engineering that we're doing at iRobot. And that just creates a unique set of challenges, but it's part of what makes it interesting from an engineering organization point of view.
Yeah, I can imagine. I can imagine.
Get Yourself a Career at a Company That Prioritizes Engineering (15:41)
So I want to diverge a little bit from the topic of firmware.
I'm always fascinated by how people got to where they are because there are no repeatable career paths. Right?
I would agree.
You were at Thomson when set-top box ruled the consumer space. Then you had a substantial leadership role at Bose Corporation, hands down the sweetheart brand of consumer audio.
And now, in leading the engineering organization at iRobot, you're ultimately tasked with bringing world-class robotics to the consumer's hands for yet another industry leader. Now, some people can slip upwards through the cracks where they work—whether it's through friendships with the right people or simply blind spots in the executive committee. It's called failing up, right? And it happens all the time.
But you really can't get away with that in a technical organization, right? Like engineering, I feel is a very honest, very pure proving ground. The same way that say a comedy club tests a comedian or a jazz club tests a musician, it works or it doesn't. No room for imposters. And I think your success at these top consumer electronics companies really speaks to your abilities as both an engineer, but also as a strategic business thinker. It's really an interesting combination of talents.
Yeah. Yeah. I feel really fortunate. Honestly, Dave. iRobot is a cool company and I feel that the technology is interesting, but I also feel the company is interesting.
The products, I think have a fan base and a following, right? I mean, you see it in the media all the time. People talk about their Roombas and the products that we make. It's fun to watch, it really is. I feel really fortunate being a part of a company that's like this, working with the people that I get to work with.
How you get through a career like this? I couldn't agree more. Some of it is just timing. Some of it is just being in the right place at the right time. There is no real path to it. The thing that I... it's interesting, is I've thought about my career at different times. One of the things I think that's, at least I feel it's helped me is, I wanted to work at companies that cared about engineering, that it was an important part of who they were. And that's one of the things I value highly about iRobot. It was very present in Bose as well, too.
As a premium branded company, iRobot tries to solve problems for people, but they're often doing it through technology, and so the technology we create, and the way we deliver it through our products, whether it's in the software or the hardware, it's essential to who we are. And I love being part of the company that values the work that way.
And so, being attached to a company like that, it's great, and then it gives you opportunities that maybe you wouldn't have at other companies too sometimes.
Absolutely. If you're in technology, you tend to want to solve real problems. I mean that's the essence of technology, improving our quality of life. And I think if you're not sure what problems you're trying to solve or why, then you're really just floating in a current of sales and marketing whims.
What I've come to appreciate about really good engineering companies—iRobot, Bose, wherever—here are companies that build advanced electronic solutions that not only improve a person's day-to-day, but make it substantially better.
You know, single guy living with a couple of Siberian Huskies, dog hair everywhere. You unbox a Roomba, hit go, and within a few minutes you realize, "Hey, my life was already pretty awesome. I didn't know it could be this awesome." Right? And same thing with Bose, where it's like, "Look, I knew that things would sound better with a good home theater, but I didn't know that watching a Pixar movie with my kids could be this enjoyable."
It's got to be so much fun to take on these challenges on behalf of the consumer, and then deliver groundbreaking products that they don't even know about yet.
No, totally. I was smiling, listening to you describe the experiences and the products. That's one of the reasons why I like being at iRobot, because it's such a relatable product for many people.
And when I first started my career, I worked in defense and there's lots of great opportunities in careers in defense. But one of the things I wanted was to be able to work in consumer, so that I could talk to people about my work. And when I hear somebody light up about a Roomba story or about how they've experienced the product or what they think is great about it, there just you can't not smile.
I mean, it's part of what gives me energy attached to the things that we do, because they're hard. But at the same time, you get a chance to see somebody light up when they experience the product. It really makes it all worthwhile.
Sean Newton, STMicroelectronics (21:32)
Although iRobot's engineering team comprises mostly software engineers, there are many mid- and small-cap engineering companies that simply don't have the resources to staff teams of developers. If you work at one of these companies, and you don't have expertise in code design, what are your options?
Sean Newton is a microcontroller applications manager at STMicroelectronics. His team supports thousands of customers, and he shares with us his perspective on how we engineers can build coding proficiency, and why we should.
Sean, welcome to the Lobby.
The Advantages of Embedded Control (AKA Why It's on the Rise) (21:49)
What would you say are some recent application sectors that are adopting microcontrollers or embedded control at an accelerated clip? 20 years ago, you would have said lighting and appliance controls, maybe even certain power supply manufacturers were introducing more and more embedded controls into the power supplies.
Nowadays, are there still pockets of the industry that were slow to adopt microcontroller usage, but are now finding that it's actually advantageous to bring in embedded control?
Yes, it's been around for 10, 15 years. But digital motor control has been around for some time—all sorts of different types of motors, PSM (permanent magnet synchronous motors), FOC (field-oriented control). That type of application has driven a lot of new features in microcontrollers recently. Plus the integration of additional analog components such as comparators, op-amps, and ADCs necessary for completing a whole system.
In recent developments, I would say also that we've seen great interest recently in digital-controlled power supply. Typically, the power supply markets have been driven by analog controllers, dedicated analog controllers. But what we're finding now is that the frequency of microcontrollers and the analog peripherals are such that we can now control digital power supplies, different levels as well. So if you're creating a buck-boost or equivalent circuit, or if you need a PFC (power factor correction) front end, the microcontroller has the capability of controlling that very well.
And that gives you some additional advantages over the traditional analog controls. Not only can you develop new control algorithms, but you also have a wide range of parameters you can now, on the fly, basically adjust for.
You still have your fixed hardware parameters—your RLC-type constraints, your capacitance, and your inductors and all your designs that you have to take into consideration—but you can definitely play around with things such as your frequency, your PWM frequencies for ideal matching.
And there's a lot of new techniques coming out that help smooth that digital control and actually give you an advantage over what we've had in analog control in the past.
See, that makes a lot of sense to me because, really, the essence of it is you're looking at the output, you're looking at the load demand, you're looking at what you know you can characterize, what the supply is capable of for a given load demand. But now you can just respond, say, that much faster, maybe that much more accurately?
That's correct. The speeds of microcontrollers—you can get up to around 150 or higher megahertz on a microcontroller and generating substantial calculation speeds. And we're finding that we can look at the total calculation times and they're well within what you need for traditional analog control, if not better.
And you have the ability to adjust some of these parameters on the fly and optimize your control algorithms, which is rather exciting.
Programs and Tools for Algorithm Development—And the Dominance of Coding in C (25:12)
To add to that, there are several engineering programs, as well, software programs you can use and tools. You may have heard of MATLAB, and there are some other power control tools that we have out there. Biricha is another one that has algorithm development tools that help you use microcontrollers to develop whatever algorithm you need to control your power output based on your application.
What is the output, for example, if I'm using MATLAB to either design or even fine-tune? Is it executable? Is it source code?
Typically, it's source code. In the embedded world, especially the one I live in with 32-bit microcontrollers, I would say 80, 85% of the market's probably coding in C.
I don't know if you saw the results of the latest software pool, but I believe that C has become the number one, as far as coding in the world again. The C language is still in everything we do. It's basically embedded... if you look at microprocessors, as well, it's embedded in low-level windows, it's embedded in Linux. It's embedded in a lot of different applications that have to use a higher-level language, but at the hardware level it hasn't gone away.
So the algorithms are exported in basically C language with .c files, .h files that you can take into your embedded project and wrap that into what you need to control for your overall system.
Biricha is a partner of STMicroelectronics and that Biricha tool allows you to put all your parameters in, it'll help calculate your control algorithms, what you need to do. And it's a really powerful tool to get you started with microcontroller design. MATLAB has a similar feature. Of course, MATLAB's used for more mathematical simulation, but it allows you to develop your algorithms and export them in C and .h files and then you can put them into your project and test them out.
The secondary tool that we have for motor control that we've improved greatly over the years is our motor control workbench. It's a similar tool.
You would specify your motor characteristics, how many pole pairs you have, your power supply, what you need to drive that motor. And you can connect through your power stage, your motor, and the tool will actually do a motor characterization for you and find your ideal tuning parameters based on some characterization algorithms it has to help initially set your control rhythms so that you know what you need to start your motor, start spinning your motor, what you need for velocity versus torque control.
So these tools have come a long way, especially in the digital realm to take advantage of the digital architecture and the flexibility you have to build different motor control or power supply algorithms for your application.
As more motor control and power supply applications are adopting microcontrollers, are we starting to see new integrations in terms of peripherals or macrocells that would enable these applications directly from the micro?
More or less. I like to look at a microcontroller... the way I look at it is that you have your CPU there, but the microcontroller is much more than the CPU. It has advanced peripherals. And so if you're going to drive a motor, the first thing you need is a decent timer. You need to have a timer that can output basically six complementary signals—basically there are three pairs for three-phase motor control. And then you need to have an ADC at least. And then you may want to have other circuitry for analogs, such as comparators or op-amp for measuring certain characteristics.
But the main thing with the microcontroller is what you may have called the macrocells. I would refer to that as linkage. We have very good tight linkage between the timers, the ADCs, the comparators, the op-amps, and the CPU.
And what that brings to the table is the ability to architect a very solid deterministic system within the microcontroller. So that a timer event goes off which can automatically trigger a DMA transfer from an ADC into RAM, which will trigger another event, which will eventually give your calculations in your CPU, for your control algorithms, the ability to go off and calculate. And then once that's done, it could feed it back into the timers well before the timers update events occur. And what you get there is a very tight, real-time, deterministic control system with very little CPU interaction.
You can use that CPU just for calculations, but everything else is... the waveforms are generated automatically. The PWMs are generated automatically. The ADCs can read based off triggers from the timers. You can do the same thing for op-amps and for comparators. So that linkage is what I would say is critical for some of these advanced real-time applications.
Are Most Engineers Fluent in Firmware? (30:59)
Changing gears a little bit here, do you find that the strong majority of the companies that you're working with have very proficient firmware engineers or are there engineers who are very skilled in their particular application who kind of learn firmware as a second language, so to speak?
I see a spectrum of customers with a variety of embedded skillsets. Customers that are building your electronic components with microcontrollers, spitting out millions of units a year, will have what I consider the professional embedded development team there. They'll be very fluent in C and C++ and all the tools needed to develop on a microcontroller. They'll have multiple firmware engineers on board, very solid tightly coupled validation, non-regression testing needed to birth your product.
However, I would say that a majority of customers that we run into are what I consider... They have one to two, three firmware engineers that do a lot of everything. They're tightly coupled with their hardware designs and they don't have the great resources as a tier-one company, but they have enough behind them. They'd still know the C coding language very well. They know the tools very well.
And, of course, with iterative product development cycles, they can take one design and move to the next one and improve what they have. So again, those are using a lot of our tools.
We find that a lot of those customers will use our examples and our firmware libraries to get off the ground and actually maybe use some of that as they move toward their production to vet that out. And that will be more the majority.
And then I'd say there's a slight minority where you have people that are more hardware and not very much savvy in coding at the embedded level with firmware. Now, with those customers, they come into two classes. Ones that are really new and they are trying to learn and we supplement our material. We have a lot of training material that we've developed on video lately. We have the ST YouTube channel where you can find several embedded training topics right now, out on YouTube to help people get started out of the box.
If they're a major customer and they still are lacking the firmware background, typically what we do is we will go to consultants or third parties that have that background and bring them into the design. Introduce them to the customer and make sure that they have what they need to get their firmer off the ground. Because it is a design cycle, it is a specific skillset. You need to take the time to know what it is you're doing and all the techniques around that to make your product the best it can be. And so techniques around that too, to make your product the best it can be. And so our network of consultants and third parties that can help customers get off the ground is very important as well. And we've seen several customers that actually have taken advantage of that to get their product out the door, especially for time-to-the-market. So that helps supplement engineering teams that may not have that embedded for more background.
You can spend your life specializing in embedded programming in the firmware library. And a lot of these consultants have done that.
Resources for Gaining Embedded Firmware Literacy (34:22)
The third category where they say, "Well, we definitely need help," we'll say. Or "We don't have a lot of expertise in firmware." You had mentioned various resources that those types of engineers can take advantage of. What are some of those resources?
So if you're a hardware designer and you want to learn microcontrollers, I would advise one, go to our ST YouTube channel, look for the STM32G0 [video] to get started. Buy a board, buy a USB cable, download the IDE software as instructed in the video. And that will get you started.
And there are plenty of resources, education-wise, to teach you C, embedded C, to help you with debugging, to understand how things work. You have enough feedback from these training sessions to get going and start.
It's a long road. So the first step is to get started, get it out of the box, and then start your continuous education on the embedded programming side.
You can go to one of the distributors—Digi-Key or Mouser—and pick up an STM32G0 Nucleo board or discovery kit. And I think there are about $10, $15, maybe max, to get started. You buy a USB cable. You can download the toolchain, which means you could download what we consider our Cube IDE for free, install that, and start going through those videos and they'll give you a very rudimentary basics how to get started.
The beauty with the modern microcontroller today, especially with the Arm Cortex devices, is the ability to immediately download your code into flash and run, and also debug basically on the fly. It's basically instant.
You may remember the days when we used to have to program double0-E prongs. And if we made a mistake, you had to go out there and reflash them with ultraviolet light.
Yep. Yep. And those enormous evaluation boards, too, that were just huge.
Yeah. Or the days of emulations for microcontrollers, you'd buy the emulator before you'd buy any silicon. So that you'd have some software there, so that you can code everything up in an emulator. And once you're ready to go, then you might buy the silicon and then maybe one-time program it.
That's right. That was my era.
Yeah. So the tools we have today are just phenomenal. If I look back in my education—and I graduated university in 1990—we didn't really have any in-chip debugging. Now we have that.
You could download your flash and in the same command, fire up your debugger. And you can single-step through your code, looking at almost any variable in memory space, which is a humongous advantage in getting started today. Especially when you look at the embedded level and it's those types of tools really facilitate getting people out of the box quickly.
And, again, for those customers that may be struggling with embedded firmware, if you have a very viable project, don't hesitate to call a consultant. There are some fantastic people out there that can get stuff out the door very, very quickly for you, and they can also help train your workforce up in the future.
So there's definitely that industry out there that can help folks get off the ground. There are lots of training consultants out there that can help take teams of two or three people and get them started with embedded programming and go through major initiatives, such as security or safety or design considerations.
As we've talked about, when you go into a microcontroller, it is a system to start with. A microcontroller is a unique system in and of itself that you need to understand. And there are a lot of components that you are going to want to learn about to solidify your design. So these consultants definitely help get you on the right track and use the features of a microcontroller to help produce a very high-quality design.
I love it. I love it. Choose what you want to be an expert in.
Bridging the Gap Between Analog and Digital Engineering (38:53)
Yes. I still see what I consider this gap between analog engineers and digital, and those people that are specialized in analog domains have tremendous knowledge of how things work. And then the move into a secondary coding, it could be somewhat painful.
So I believe this gap is definitely something that's going to be crossed. And so, it takes some time and you've got to take the time, set out a goal of one to two years to learn as much as you can on the embedded space. Start programming today. And just take it one day at a time. And then, as you start learning the different techniques and the different coding practices, you'll able to take your analog knowledge and bring it into the digital realm.
Right. Exactly. And like you said, it just compliments your skillset.
When I came out of college, University of Miami, I was focusing on digital audio and what I came away with was a very, very strong understanding of DSP. My languages of choice were Assembly and C++, but I got a big reality check when I entered the industry.
So you have to leverage what you're good at, obviously, but extending your skills and your capabilities does not have to be painful if you're choosing the right tools and the right resources to help get you started.
That's correct. And again, it's a learning curve on both sides.
Your digital audio experience today is probably extremely valuable. If you look at how audio has shaped up, digital microphones and signal processing, especially... That's another area we didn't talk about, but audio, and again, with the processing capabilities we have and our modern-day microcontrollers, you can do many of the audio filterings you need digitally. You don't need the extra circuitry to do that. And you have the ability, once you put it in digital, to create whatever effects you want for your audio to work.
Absolutely. The 32-bit performance, just operating at blazing-fast speeds. I don't need to go find a highly specialized DSP and do things in Assembly anymore. I can actually control a circuit using the exact same controller that's running my audio processing algorithms.
Yeah. I've really watched that slide audio file myself. I've been working on audio projects since I started with STM32 and watched the birth of the Arm Cortex and slowly being able to benchmark our DSP capabilities with the Arm Cortex up to these traditional DSP processors. And we're still continuing that roadmap today.
So it's been interesting to see how we've shifted away from 8-bit to 16-bit. Now we're looking at, okay, the high-end DSPs are 24-bit. Are we going to be able to supplement with standard cores?
And the beauty of the microcontroller is that once you brought the general-purpose microcontroller in, you can do some of this DSP. You did not need that specialized device for all your high math. So you could put it in one device, have all your control on one device. And if you have the performance and bandwidth to do that, it really simplified the designs.
Absolutely. Totally agree.
Oh, man. Okay. So now we have two follow up episodes that we need to go record. One will be IoT device security. The next will be microcontrollers for high-performance audio.
I'd be happy to do that and happy to bring some of my experts on as well to discuss some of the intimate details there.
Ah, let's do it. This would be great. All right, cool. Now I'm just being greedy, but I really, really do appreciate your time. This has been fabulous.
All right, well, thank you very much, Dave.
Yep. Thanks, Sean.
Huge thanks to our guests Tim Saeger and Sean Newton, who joined us from their home offices this week to lend their perspectives.
And we want to hear from you. Are you pretty well-versed in software development? Do you know just enough to be dangerous? Or is firmware not even on your radar at this point?
Drop your thoughts into the comments section on AllAboutCircuits.com.
And, if you enjoy, Moore's Lobby, please leave us a review online and take a moment to subscribe. It's a small gesture that goes a long way in helping us to build a meaningful community of listeners and contributors.
Thanks for listening.