The Embedded Frontier

#014 - Modernizing Embedded Systems: A 7-Step Framework

• Jacob Beningo

Share episode

Summary

In this episode of the Embedded Frontier Podcast, Jacob Beningo introduces a comprehensive framework for modernizing embedded systems development. He discusses the importance of adapting to modern techniques in firmware development, emphasizing the need for a shift in workflows, architectures, and tools. The episode outlines a seven-step process that includes modernizing build systems, improving software architecture, implementing DevOps practices, embracing test-driven development, leveraging simulation, adopting AI and machine learning, and establishing a metrics scoreboard to track progress. Each step is designed to help teams develop faster and smarter firmware, ultimately leading to more efficient and effective embedded systems development.


Takeaways

  • Modernizing firmware is essential for efficient development.
  • The seven-step modernization framework includes build systems, architecture, DevOps, testing, simulation, AI, and metrics.
  • Modern build systems should support various developer tools and environments.
  • Software architecture must be scalable and flexible, separating application code from hardware.
  • DevOps is crucial for improving collaboration and speeding up development cycles.
  • Testing should be prioritized, with an emphasis on test-driven development (TDD).
  • Simulation can help developers test application code without hardware dependencies.
  • AI and machine learning can enhance both on-chip processing and development workflows.
  • Metrics are essential for tracking progress and identifying areas for improvement.

The framework aims to help teams deliver better products on time and within budget.


Keywords

embedded systems, firmware development, modernization framework, build systems, DevOps, test-driven development, simulation, AI, machine learning, metrics

Jacob Beningo (00:08.216)
Welcome to the Embedded Frontier Podcast, where we explore modern embedded systems development techniques so that you and your team can develop faster, smarter firmware. I'm your host, Beningo, founder of Beningo Embedded Group, the Embedded Software Academy and co-founder of the Embedded Online Conference.

In today's episode, we are going to be talking about how to help you develop faster, smarter firmware. In fact, what we're going to be doing is starting an entire series that's designed to walk you through the steps necessary to help you modernize your firmware. Now, you might be saying, Jacob, I don't need to modernize my firmware. The processes and techniques I'm using are just fine. But that leaves me with a couple of questions for you. Do you currently get stuck waiting for the hardware team to deliver hardware so that you can get done what needs to be done?

Are you getting your software in front of the customer less than a month after you start a new project? Are you finding that you are spending more than 40 % of your time debugging your software? If you're answering yes to any of these questions, then the chances are you're not using modern development techniques. In fact, I found that a lot of us, once we prove that technique works, we kind of become stuck. We keep using that technique over and over and over again. Why?

because it worked. It's a solution that we know solves the problem. And that's a good thing to have, be able to walk over and grab a hammer off the shelf, right? When you need a hammer. But what happens when a hammer actually doesn't apply for that particular solution anymore? But you don't know that there's anything but a hammer to solve the problem. What if you went around and tried to build a house with just a hammer rather than going out and getting a nail gun? There's often times where we have to modernize our skill sets, modernize our workflows.

and modernize the way that our teams interact with each other. It's not because we're not necessarily doing things the right way. It's simply that our industry is evolving at a rapid rate and that rapid rate of of change forces us to go back and reevaluate how we're going about building embedded systems. Now, when we talk about embedded systems, I like to focus in on the firmware, right? Like I said, we want to modernize our embedded software. We want to build faster, smarter firmware. But at end of the day,

Jacob Beningo (02:25.368)
we are building systems, embedded systems. And these systems all have three pieces that have to come together, right? There's the actual physical hardware, there's the electronics, and there's actually the firmware. Okay? All three of these pieces have to come together. What we are going to be doing here is we're kicking off a series that's going to help you bring all those pieces together, help you start to think about what your modern workflows should look like, and help you to modernize your software, all right? So that you can build faster, smarter.

And as part of that, this is actually going to, what I'm going to do is I'm going to introduce you to a seven step framework that I use with a lot of my customers. And even though improve my own development efforts, that is going to help guide you on the key pieces where I see a lot of modernization needs to be done in teams today. Now, this doesn't mean that these are the only things. There's actually quite a bit that I see teams struggling with, but in general, I found that if you can modernize these seven key areas,

then you're going to be a lot further along and at least raise and improve your chances of delivering on time and budget. Okay. Now, of course, every team is going to have their own issues and their own struggles. some of these areas you might already have figured out. Some of them you might need extra help on. Some of them maybe you need my help on. I don't know. Whatever it happens to be. What we're going to be doing here is introducing you these seven steps to modernize your embedded software. And I'm going to give you an overview of what that looks like today. And then over the course of the next

several sessions, we are going to be talking in detail about each step and then following each of the in-depth steps, I'm actually going have a guest on who is going to talk about what they're doing, what they're seeing. And that really embodies the modernization effort in each of those steps. All right. So with that in mind, let's take a look at what the seven steps consist of. Now, first of all, our seven step process is going to step one is modernization of our build system.

Okay. Second, we are going to improve our architecture, our software architecture. Step three is all about DevOps. All right. Continuous integration, continuous deployment and observability. Step four is test driven development. It's all about testing, right? From there, we talk about simulation. One of my favorite topics. This can be functional. This can be a chip level simulation. There's all kinds of interesting things we can do there. So step five is going to be that we want to make sure that we're

Jacob Beningo (04:52.839)
simulating our software. Step six is going to be adopting AI and ML technologies. And then finally, step seven is going to be a metric scoreboard to keep track of where you are and where you need to get to. OK, so with that in mind, let's dive in and start talking about each of these for now in a little bit of a high level detail. And then as I mentioned in future episodes, we'll dive in much deeper in order to help you build faster, smarter firms.

So today, what I'm going to do is introduce you to each of these seven steps. Now, the first step, as I mentioned, is to modernize your build system. Today, there are lots of different ways that we can build our software, but I do find a lot of teams, you know, depending on who they are, how they're setting things up, a lot are dependent on some type of integrated development environment to develop their software, right? And certainly we love, you know, what's provided by our Silicon vendors. They put a lot of work into helping provide us with integrated tooling.

to help us to accelerate the way that we develop things. But what does a modern development or build system look like today? Well, step one, this build system comes with a lot of different features. Okay. There's need for flexibility. Within a team, I might have some developers who love to use the integrated development environment from the Silicon vendor. There might be others who love to use Visual Studio Code. There might be others who maybe like to use Sublime Text. Maybe there's others who just like to work straight out of a terminal.

Maybe they're using Nano or whatever it is that they like to use. And we need to be able to support all of these different IDEs, different preferences for build systems so that each developer can actually be as efficient as they can based on the tools and the skill sets that they have. And so part of modernizing a build system today needs to involve the developer experience, the tools that they use, but it also needs to look at how their workflow is set up so that they can build software.

and even the tools that they're using to organize the different modules and software assets that they're actually building. Now, just to give you a little bit of a preview of what this actually entails, a build system today, as I mentioned, involves some type of IDE integration. A lot of times we're containerizing them. So we're using Docker or some type of container technology to be able to containerize our build systems. By doing that, that will allow us to go forward and share our development environments across

Jacob Beningo (07:18.021)
across teams and across developers without fighting with issues like, this is compiling on this machine, but it's not compiling over here. And all these libraries are aren't the same version or that you have a different version of the compiler because yours auto updated last night and mine didn't. There's all of those types of little things that get in the way of us being productive and efficient. Right. So a modern build system today should have a good IDE. It should be some type of containerized environment. It should probably use some modern build system generator.

Yes, we use make behind the scenes. It's a great tool. It's been around for a long time. But using tools like CMake today, we're finding are really one of the most popular build system generators. Okay, so understanding CMake and how that fits into building your system to generate your make files and then build your final artifacts for development are extraordinarily important. Okay. On top of that, the build systems today, they're not just, I would say, considering just how you build things.

What's also important is how you're organizing your project. lots of people love to throw everything into a single repo and you have this one repo that has all of your assets for your project. Well, as it turns out today, that's actually not maybe the best way to do things. There are, you know, if you're building a platform based system where you are going to have to support multiple customers, maybe even multiple product lines as well over the course of, let's say, five or ten years.

Throwing everything in a single repo just isn't going to work. OK. But that's where tools that from the open source community are extraordinarily useful. We've seen Zephyr we're going to use as an example of a modern build system and even modern architecture and some things like that. So the stuff that they're doing with Zephyr RTOS is extraordinarily helpful and a great example of modern firmware development. And what we're going to see is that tools like West allow us to have multiple repos that we can then pull into a single project. So we end up with these

sub-repos essentially that we can create recipes for that bring different assets into a project based on whether we need them or not. And so by doing that, we can actually make sure we're getting the right version of a repo, right version of our libraries, right version of software for specific customers. And it really integrates everything into a nice clean environment for us. OK. There's also technologies like K-Config that allow us to individually configure our overall build system, individual libraries within our projects as well.

Jacob Beningo (09:45.505)
Those are a couple of really good examples of tools that you can leverage in order to modernize your build system. OK, so we're to be going into more detail about what that looks like in the coming episodes. This episode, we're all about understanding what the seven steps are to help you modernize your software development processes. OK, so build systems. Number one thing, you got to have a good foundation that you're building all of your software on from that build system, kind of in parallel to this or even kind of the second step.

once you kind of have a nice build system all set up and ready to go is software architecture. OK, the architecture that you are using for your system has to be scalable, flexible. And I'm going to argue modern. OK, there's still a lot of systems that I come across where the application code is tightly coupled to the hardware. All right. Now, in the past, that made a lot of sense because the software.

access hardware that, you know, the hardware itself wasn't very, you know, high performance. It didn't have a lot of processing capability. We were resource constrained in embedded systems and firmware development. And so what did we do? We cut out all the extra layers, the abstractions, and we tightly coupled our application code to the hardware in order to save a little bit of memory and to save those clock cycles. All right. But if you look at the processors that are used today, the different ARM architectures, for example, that a lot of folks use, and there's certainly other proprietary ones out there.

Right? But if you look at the different architectures, our processors are extremely powerful today. All right? You look at a Cortex-M23. Some of them have a megabyte or two megabytes worth of flash space. Some of the parts I've seen have clock speeds up to a gigahertz. Okay? Some of them are adding neural processors and all kinds of cool things that make it so that we can execute a lot of stuff in a very small package very cheaply. Okay?

And so the bottleneck today really isn't the hardware. The hardware is more than capable of running the software that we need. And so from an architectural standpoint, I always argue that we should separate our architecture into two different architectures, a real time architecture that directly works with the hardware. This could be considered our firmware, right? Kind of that traditional firmware development. And then there should be application code above that through an abstraction layer. That application code should

Jacob Beningo (12:05.377)
be the stuff that solves our customers' problems. It's the business logic of our application, OK? I know some developers hate that language, OK? But the truth of the matter is, is at that higher level, it's the application features that the customer cares about. It's the forward-facing stuff, customer-centric side, OK? And so oftentimes, one of my design principles that you'll often hear me talk about is that I say there is no hardware, only data. And I love saying that because it really riles up the hardware folks, right? But the fact of the matter is,

What I'm trying to get at when I come up with that principle is that our software should be our features of our app of our software should be separated from the hardware. That doesn't mean that hardware is not important, but what it does is it helps us test out our application code early in the development cycle. It unlocks important modern capabilities and tools like DevOps, test driven development, simulation. All right. These are important techniques that can help firmware teams develop their systems faster, more efficiently.

and overall, hopefully get them to deliver on time and on budget, right? Which is the goal that all of us have, right? And so with that, if you architect your system in that way, it will help you not just modernize your software, but it'll unlock those techniques and help you move towards being able to actually deliver on time and on budget, okay? All right, so that's the second step, architecture. And we're going to be talking in more detail in the future about how you modernize your architecture. We're going to be talking about things like architecture characteristics,

We're going to talk about principles and philosophies. We'll talk a little bit about architectural design records and then the structure of your architecture, right? The actual structural or the kind of the design patterns that you're using. Now, obviously, we can't go into nitty gritty details of all of that, right? That's why I have my embedded software architecture masterclass as part of the embedded software academy. But I'm still going to give you the ideas and the concepts that you can go back to your team with and kind of think through what is important for modernizing your own

architecture. All right. So that's a second step. We got build systems, architectures. The third step is to implement DevOps. All right. If you have a really good build system and you've architected your software properly, then what you should be able to do is leverage DevOps. Now, for a long time in the embed systems industry, we said, no, no, no, we're special. DevOps doesn't apply to us. We're a very specialized case. We talk to the hardware. We can't leverage DevOps successfully. And

Jacob Beningo (14:33.997)
you know, over a couple of years, obviously, our industry discovers, oh, no, no, no, this is actually really important. All right. And so right now there's a big trend in the industry of adopting DevOps and DevOps. Oftentimes as developers, we look at it from a code development standpoint. All right. So if I'm looking at DevOps from a developer standpoint, I'm thinking build pipelines, analysis pipelines, know, deployment pipelines, the actual physical stuff that

I'm going to use in my workflow, right? But DevOps also goes beyond those types of concepts. It actually is about a cultural change. It's about recognizing that we can iterate, OK, over our software in very short periods of time, that we can get automated tests, that there's a lot of manual work that we do as embedded software developers and embedded systems developers, that we can actually automate using these DevOps platforms. Ultimately, DevOps is about going faster incrementally. And it's also about

across cultural interactions across teams. Okay. So if I'm a developer, I'm not just staying in my own silo. I should also be working with, you know, the quality team and I should be working with, you know, management and so on and so forth, right? To ensure that what we're actually delivering to our customers is important. Now DevOps covers, like I mentioned, build pipelines, delivery pipelines. It's all about getting your software and your features to the customer, right? And so you can imagine that as a pipeline going,

You know, from the left to the right, from the company to the customer. But DevOps is more than just delivering faster. Okay. It's also about getting feedback from the customer to the company, to the developers. And that often comes in the, know, it comes dressed as observability. Okay. Observability is critically important. I need it. You need to be able to observe your systems in the field. You need to be able to get that feedback from the customer. Is your system working the way that you expect it to be in the field?

Are the customers using the features that you expect them to use? Are they using those features in the way that you thought they would use them? Right? If you can get that feedback loop that can then feed into how you develop software and how you release it, making your product better with each iteration of the cycle. All right? And so DevOps isn't simply a, need to go faster so that I can bang out more code and maybe have a higher quality system at the end of the day. Right? It's actually about an interaction with us within our company across

Jacob Beningo (16:59.617)
different teams, so we're not siloed and pushing, you know, people love to, you know, this isn't my problem. This isn't my problem. You know, we work together to successfully deliver features to the customer. And then it's also about getting that feedback from the customer so that we can provide more value to them. Okay. I also call this a value feedback loop within DevOps for that delivery and that feedback pipeline. Okay. So we'll talk more about that here in some of the coming episodes. Now the fourth.

step in the seven step modernization framework is all about testing. All right. One of my principles oftentimes is that we should test, test and test. All right. Now, DevOps certainly enables the ability for us to perform automated regression tests, automated unit testing, and so on and so forth. Right. And if we're going to have DevOps set up, then we should be taking advantage of test driven development. Now, I know that for many embedded systems teams, adopting test driven development

is challenging. OK, we are interacting with hardware. Does it make sense for us to create unit testing for, you know, drivers are going to be on the hardware, getting in the mindset of, you know, writing a test first, making it fail, then making a small change, making the test pass and then refactoring. That is kind of difficult for embedded systems developers. I know when I sat in on James Greening's TDD workshop, I'll say.

I attended one of his workshops. It was like a half day workshop, I think, at the Embed Systems Conference, probably more than a decade ago. And I remember sitting in there going through this and saying, well, I can see the value. I can see how this could be very helpful. But this doesn't really apply to Embed Systems developers, right? I'm not, you know, I have these hardware dependencies and sure, I could mock out all that stuff. But at the end of the day, that's a lot of extra work for maybe not a lot of extra value, right? And so I kind of sat for, I'll say a year or two.

with the idea of TDD percolating in my mind. Before one day I sat down and said, you know, the way that I develop software, I really focus on data-centric design. I really abstract out the hardware. Why can't I apply TDD to at least my application code? Even if I don't want to go through the work of, you know, doing unit testing for my low-level firmware, I can at least prove that my high-level application features work the way they're supposed to. And I started to adopt TDD at the application level.

Jacob Beningo (19:26.093)
And I discovered that I had been missing out for the previous two years. It helped me be a little bit more efficient. It helped me write code that was cleaner, testable. I could automate those tests. I'm not going to lie. I would write code and you'd discover a month later that there was a problem. And then you'd forget what you had done a month ago and you had to go back in and spend a couple of days doing all this stuff. And then finally you find the bug and you go, oh my gosh, this is some stupid thing. You did a...

an equal sign is 7 or equal or something like that, right? Some very simple trivial error, but it was maybe hard to find in the code. But if you'd written the right test ahead of time, you would have found it right away and been able to fix it. OK, or maybe you write a new module and it interacts with some other feature. And if you're not doing CI, CD with it, then you don't know that that feature is, you know, one new feature, broken old feature until three months later when you're trying to do all of your aggression testing before you release the product. That's not where you want to be, right?

And so I have found that test-driven development really helps me find my mistakes, helps me find bugs a lot faster, usually right after I develop the system, right? And having tests that directly, you know, a test for every line of production code that covers all the use cases. man, I'm telling you, it has dramatically improved the quality of my embedded software. I often feel guilty if I'm not following TDD, okay? If I'm not writing a test first before I write a line of code, I literally feel like, boy.

What am I going to miss here? And I'll be honest, a lot of times if I'm writing code like that, it's really just probably one-off prototype code or example code, right, for some article or course or something like that that I'm working on. But the benefits I've seen from TDD are extraordinary, okay? Now, even if your team has failed at test-driven development, that doesn't mean that you can't still adopt some of the ideas so that you can write more unit tests, so that you can start to automate some of your testing, all right? So...

We're going to be talking more and more about test-driven development and what also system level testing, because it's not just about using TDD at a unit, at a function level to test, to do unit testing. TDD can actually be thought about from a system level where you look at a system level feature and say, hey, I need a system test that verifies that an LED blinks, you know, and then say, now I have to break down everything that I need to be able to successfully perform that test inside the firmware. Now, maybe I need

Jacob Beningo (21:48.518)
you know, a command or something that goes over some serial interface, which then requires it. And you can use it as a way to develop system level tests and then break your firmware down as well. All right. So lots of cool benefits there to some of those techniques. All right. So that's the fourth step. So you get your build system squared away and modernized. You develop an architecture that is modern and scalable and flexible. You set up DevOps so that you can have automation. You can have continuous building.

continuous analysis, continuous deployment if you want. And then yeah, for embedded teams, continuous deployment. I agree, shouldn't be updating your microwave firmware every two hours or something like that. Maybe it's a quarterly release. And then we have fourth, our test-driven development. Now the fifth step, and this is the one that I honestly am maybe the most excited about. Although I'm going to tell you what, I love all of these steps. So maybe there isn't one that I like more than the other, but I think this step,

Step five is the one I see maybe the most benefit to teams to develop or adopt, and that's simulation. Traditionally, microcontroller-based events software developers have not adopted simulation. Once again, we say, no, no, no, that's not really for us. Yeah, I could go and get some hardware models, you know, using maybe like Renode, for example, but maybe that's beyond what we really need to be doing for our systems. At a minimum, simulation can be functional simulation, all right? Again, testing your application code,

to prove that those application features work the way that they're supposed to. This goes back again to the principle that I love to push, that there is no hardware only data. All right? This is a data-centric approach or thinking about things. If I focus on architecting my system around the data assets and I use proper abstractions, there's no reason why I cannot simulate my application code and prove out very early that it's doing what it's supposed to. If I can simulate my software,

I can get it in front of the customer sooner. I can get customer feedback earlier, which means I can make those adjustments the customer wants without, you know, maybe having myself tightly coupled with low level hardware, being dependent on the hardware team. I can actually accelerate my software development and get way ahead of the hardware team. OK, rather than being dependent on them. We all know that who gets blamed the most for late firmware. It's the embedded software developers, right? And oftentimes we'll argue, well,

Jacob Beningo (24:13.914)
We didn't have the hardware until a month ago, right? How are we supposed to move forward and get features out the door when we had to start from the bottom up in many cases, right? Now, simulation and the adoption of a modern architecture help us work from the top down. That gets us our application code first. It gets us in front of our customers. It gets that fast feedback. And yes, even though we're data centric and we say there is no hardware only data, there is hardware.

And we do want to integrate with the hardware that we're going to be running our software on as quickly as possible. That's why we use Frankenborns, right? Where we end up with, you know, a setup on our bench that is very gnarly looking, wires everywhere and all that kind of stuff, right? Because we know, even though we might be using data centric design, we still recognize that hardware is a critical piece in any embedded system, right? And there are going to be interesting reactions between hardware

and software that we just have to work out. And the sooner we can work those quirks out, the better. But that doesn't mean we have to stand around twiddling our thumbs, starting from the bottom up. And after six months of development, or maybe even a year, starting to give our customer features only to discover the entire last six months that we were working on, maybe it was for nothing, right? We want to get in front of the customer early, get that feedback, close that loop. And then at that point, yeah, we're waiting on hardware and hardware software integration. OK.

So we really want to try to leverage simulation. There's lots of techniques out there. Obviously, we can use QMU and Renode as examples, but functional simulation where you use maybe even a web server as a backend, have an abstraction layer between your application code and the hardware. You could actually underneath in place of hardware have, like I said, a socket server and your data can then be pushed that server and actually feed in fake sensor data and do all kinds of other things.

recently on LinkedIn, I actually posted about something like this. And it was quite interesting because obviously you had the people that come out and go, no, no, no, you can't do this. You can't do this. This is why this isn't going to work. And there was one gentleman who came out quite, I want to say, came out opposing the idea quite fervently. Okay. He was like, no, no, no, you can't do this. And here's why and blah, blah. And then as it turned out, a month

Jacob Beningo (26:40.134)
Six months, six weeks later, OK, I discover he's posting on LinkedIn about the functional simulation that he's doing to accelerate his embedded software development. OK, and, you know, we kind of reach out and talk to him. He's like, yeah, yeah, yeah. I couldn't get this out of my mind, even though I was totally against it. I said, you know what, I got to try this and see how it actually works. And then he tried it. And what do you know? He loved it. It actually was helping him accelerate his software development without the hardware being available to him.

And so he went from being completely opposed to this data centric simulation, functional simulation based idea to actually being a proponent of it. OK. And honestly, as developers, as engineers, that's the kind of thing we want to do. Yes, we can be opposed to an idea, but we should try it out to see does it work for us. It might not work for you or there might be a limited type of simulation that you want to adopt, right? Because of the type of system that you're building, but still.

implementing this in some way can help you move faster. All right. And we'll see that over the course of the next several months as we talk about each of these in a lot more detail. All right. Now, the sixth step to modernizing your embedded software development practices and workflow is, of course, to adopt AI and ML, OK, and machine learning. Now, I probably could have led with this, but obviously, artificial intelligence and machine learning, you can't open up a technical journal today.

without seeing them posted somewhere, right? Even on this Embedded Frontier podcast, I've struggled to stay away from talking about AI and ML constantly because there is, you know, there's so many other things for us to focus on and talk about, but the frontier is how do you use AI and machine learning to develop faster, smarter firmware, right? I mean, that's really important. So the sixth step here is that we have to have some level of adoption of AI and ML, okay?

Now, machine learning is for on chip. There are so many cool things going on with microcontroller technology today with accelerators for machine learning. There are chips out there that I have seen that have multi-core neural processors on them. These are microcontrollers, okay. They are like Cortex-M, I think these were M33s that I was looking at. neural processing units on board,

Jacob Beningo (29:06.096)
that allow you to actually run like YOLO models at 60 frames per second. Extraordinarily powerful. Okay, so we can run machine learning models on the edge. The processing power is there in our microcontrollers today. And so the only question there is how are we going to leverage this? What applications? Is it for object detection? Is it for detecting...

maintenance issues, right? Is it going to be for, know, pick whatever your problem might be or problem of interest might be, okay? It can even be to generate digital signal processing signals. One of the first machine learning applications that I actually created was just generating a sine wave, okay? And try to generate an accurate sine wave using machine learning models instead of just generating it directly out of, you know, the typical way of using the digital signal processing libraries, okay?

So those are some really trivial examples I'm talking about for machine learning. But as you can imagine, there's a lot of capability there for us to leverage. And so this step six involves us looking at machine learning and saying, how do I take advantage of this in the types of systems that I am building? All right. And on the flip side of that is the actual artificial intelligence. This is where we look at AI not to run AI on chip, but we look at AI to modernize our workflows. At the embedded online conference that's just coming up,

May 12th through the 16th, 2025. And if you missed it, don't worry, it's all recorded, so you can still go watch the material there. You can actually use my coupon code, BANINGO, and get a $50 discount on whatever the current price is. But I'm giving a workshop there that looks at different uses of AI within a workflow for embedded developers. One very simple thing to do is...

use AI as a code reviewer, right? Essentially as an intern or as an expert in, let's say, C or C++. I've had pretty good success having AI go through and literally analyze a C C++ module or add documentation to it, all right? Now, obviously, there's potential security concerns there, right? You know, your own intellectual property, you may not want AI to, you know, get your code uploaded into it, right?

Jacob Beningo (31:28.29)
Maybe you want to do that with something that's more on premise than versus in the cloud, right? But again, I have found that it is extraordinarily capable of going through and successfully analyzing code for you and giving you really good feedback. right? Adding documentation. I've even found that when I'm developing a software architecture, I can use AI to generate my documentation, to generate my diagrams.

I can actually work hand in hand with agents to generate code that then creates my visual diagrams. Okay. Or to work with it to create latech documents that will, you know, have the stuff that I need in it or the formatting of it and generate maybe even kind of the rough drafts of some of the stuff that I want to say in some of those engineering documents. Okay. So AI can be a useful tool for that. It can be a useful tool for helping you with the different steps in this modernization.

process that I have, this framework. So many different ways that you can use it. And so I would highly recommend that if you aren't using artificial intelligence or machine learning today, you very carefully start to learn those technologies. OK, lots of different ways that you can use AI to help you accelerate your development. Now, the last step that we're going to talk about today in this overview is a metric scoreboard. All right. Now, yes, this this isn't some sexy topic, right? Metrics.

probably isn't anything that's getting you, you know, it be like, yeah, let's go look at the metrics and see how things are going, right? As developers, we want to write code. We want to get down and build the system, see it working. That's what's exciting, right? But a metric scoreboard is critically important because it helps us know where we're at. And it lets us know where maybe we're falling short or maybe where we're doing a really good job. And so part of any modernization framework in my mind is that we have to develop metrics that we're going to track.

to make sure that we're moving forward in the right direction. Okay? There's lots of different metrics that you can track with software, with project management. When I'm looking at software, example, cyclomatic complexity is one of my favorites. This just lets me know, is my code complex? Is it testable? What are some of the issues there that maybe we could end up encountering? Complexity doesn't mean that there's something wrong with what you're developing. It just means that the code is complex and that you might end up with...

Jacob Beningo (33:48.058)
bugs hidden in there because you weren't able to fully test it or the code is so complex that it increases the probability and the risk that you'll inject a bug into the system when you go to make modifications. Okay. Now, honestly, I would have put metric scoreboard as the very first step. All right. Because things that get tracked, things that get tracked get managed, right? Or something like that. However the saying goes, right? Things that get tracked get managed, but

If I started talking about metrics right off the bat, guess what? We're all going to go to sleep. All right. But the truth of the matter is metrics are just as critically as important as any of these other steps. Right. So we're to be talking about these in a little bit more detail. I'll give you more ideas here for each of these steps. And certainly if you're saying, man, I want to, you know, I need help to modernize my embedded software and systems practices. You can always feel free to reach out to me at jacobapeningo.com and I can help.

you accelerate your modernization so that you can start to develop faster, smarter firmware much sooner. Okay. Now, I guess maybe to sum up the framework one more time before we close out, the seven-step framework to modernize your embedded systems and software practices is first, we need to modernize our build systems. We need to modernize our architectures. We need to integrate DevOps into our workflow. We need to adopt test-driven development and a

Test mentality. All right. Even if we don't go full on test driven development, testing should be in the forefront of our minds and automated as much of it as we can. The fifth step is to leverage simulation. That doesn't have to be simulation from top to bottom. This could be as simple as basic functional simulation to test out individual modules or it could be as complex as doing full on simulation of your software. All right. So there's a wide range there.

but even just a little bit can help you go a long way. The sixth step is AI integration into your workflows and adoption of machine learning on chip at the edge. Okay. Making your device a little bit smarter at the edge where it is. Okay. And then finally, it's again, those metrics scoreboard. Okay. Having metrics that you can track that let you know where you're at and how your system is, how your system and team are performing. So this is my seventh step.

Jacob Beningo (36:12.294)
framework for modernizing embedded software development. We're to be diving deeper into this over the next several episodes. In the next episode, we are going to dive deep into step one, where we are going to talk in detail about build systems. All right. I'll talk about some of the technologies that are important in build systems today, give you some ideas of things that you can adopt technologies for you to take a look at. And then from there, the episode after that, we're going to talk with Kyle Dando from NXP.

And he's actually going to talk to us about what NXP is doing in because they've been modernizing their own build systems that they provide their customers. So we're going to look at their MCU, expresso SDK and see what that does and how it can act, how it actually shows what a modern build system looks like. OK. All right. So with that in mind, I appreciate your time and attention today. If you are interested in diving further or if you have, first of all, if you have questions or comments, please feel free to leave them below.

That feedback is certainly helpful for me. So happy to hear from you and engage with you. And then certainly if you do need assistance in modernizing your embedded software practices or you need good ideas for developing faster, smarter firmware, then feel free to reach out to me at jacobepenningo.com and I am happy to help you and your team adopt modern embedded systems practices. So with that in mind, happy coding and I look forward to talking with you next time.


People on this episode

Head Shot

Jacob Beningo

Host