The Embedded Frontier

#016 - Modern Build Systems with Kyle Dando

• Jacob Beningo

Share episode

In this episode of the Embedded Frontier podcast, Jacob Beningo and Kyle Dando from NXP discuss the modernization of embedded software and firmware, focusing on the MCU Xpresso SDK. They explore the significant changes made to the SDK, including the adoption of CMake and KConfig, the introduction of West for managing software repositories, and the overall impact on developer workflows. The conversation also covers the migration path for existing users and future trends in embedded software development, emphasizing the importance of user feedback in shaping the SDK's evolution.

Takeaways

- Modern build systems are essential for embedded software development.
- The MCU Xpresso SDK packages low-level drivers and middleware for ease of use.
- Accessibility improvements were a primary focus in SDK modernization.
- CMake was adopted for its universal build capabilities and customer demand.
- West allows for efficient management of software from multiple repositories.
- KConfig simplifies project configuration and dependency management.
- Developers can choose between command line and IDE workflows.
- Migration to the new SDK is designed to minimize disruption for users.
- Future trends include support for new operating systems and ecosystems.
- User feedback is vital for continuous improvement of the SDK.

Jacob Beningo (00:01.55)
All right, well, welcome back to the Embedded Frontier podcast. We've been in the process of going through a series where we're talking about the seven steps to modernize your embedded software and firmware. You may recall that those seven steps are a modern build system, architecture, DevOps, test-driven development and testing, along with simulation, AI and machine learning, and a metric scoreboard.

Now, what we're going to be doing today is diving in and talking in detail about the build system side of things. And I've got Kyle Dando here with me from NXP. Kyle, how are you doing?

Kyle Dando (00:38.624)
I'm doing great, Jacob. Thanks for having me on.

Jacob Beningo (00:41.228)
Yeah, absolutely. And we're going to be talking about the MCU Xpresso SDK. And I think this is a great example of what a modern build system entails. And we're going to talk a little bit about that today. But before we dive in and talk about modern build systems and how they're reshaping embedded software development and how they can help you modernize your workflows, let's talk with Kyle and kind of let him give a brief introduction about himself. And that way you can get a little bit to

to know a little bit about him. So Kyle, do mind give a few words here about yourself?

Kyle Dando (01:13.516)
Sure. No problem, Jacob. So I work at NXP. based in Austin, Texas. And my passion and really my responsibility is to make sure that all of our customers have a good user experience with our software, with our development tools. So I'm on a team, a global team, and our responsibility is our SDK. So we'll talk a little bit about that.

I'm responsible for our IDEs or integrated design environments. And I also work with our configuration tools. So really that, as you talked about the development cycle, my job kind of manages all those aspects at NXP. Personally, I'm a computer engineer by trade. I have over 30 years experience, similar to you. I have lots of experience to pull from.

And I try to integrate that into the job. Personally, I am an avid runner. I've run my entire life and just recently got into sort of more of the fitness and the nutrition and weightlifting. So as a 50 year old, we try to keep on top of things.

Jacob Beningo (02:24.75)
Absolutely. And certainly, it's an important aspect, too, of being able to perform well, even as a software engineer, right? A strong physical body helps the mind and kind of can help you perform well on the job as well. So that's fantastic. So you mentioned running any other fun hobbies or activities that you do outside of software engineering, I guess?

Kyle Dando (02:46.592)
Well, it actually ties a few things together. I do Christmas lights. So I am the guy, I'm the guy in your neighborhood who does the synchronous lights to music. And I've done it for about 11 years now. And every year I add another 2000 LEDs and my neighbors have actually knocked on my door and asked me if there's any way I could maybe, you know.

Jacob Beningo (02:52.461)
Kyle Dando (03:10.038)
put a dimmer on them or slow my advancement. But I enjoy that because I love music and I love computer programming. So it kind of ties the software engineer in me to a person who enjoys music. And obviously the little kids at Christmas that come up and listen to a Frozen theme song or Baby Shark, I've got all the music.

It's a fun hobby, so it me busy.

Jacob Beningo (03:42.028)
Very cool. Very cool. Yeah, that's awesome. I've always wanted to do something like that, but never have. We've got one in our neighborhood that does that. yep, yep, exactly. Leave it to them. So, but no, that's fantastic. That's awesome. We'll have to get you to share some photos or something in the future. don't know. But anyways, I digress a little bit, no, really appreciate that sharing about your background and...

Kyle Dando (03:52.224)
Leave it to him or her.

Kyle Dando (04:01.612)
Sure.

Jacob Beningo (04:08.916)
One of the things, as you know, we want to talk about today is kind of that modernization of build systems. I know within NXP, things have been changing with the way that you guys do your SDKs, with the way your development tools are working. I've seen a really big change in kind of modernization of how you guys are providing tools. And I've had an opportunity to play with MCU Xpresso, the new SDK a little bit, but I thought it'd be great to have you on and kind of talk through some of the things that you guys have been doing, what you're thinking.

about that. maybe the first thing we could do is have you introduce what what exactly is MCU Expresso SDK.

Kyle Dando (04:42.762)
Yeah, so the MCU, as MCU, espresso SDK is our core software deliverable to customers who select NXP microcontrollers to put into their products. And what it is, is it packages the low level device drivers and, and, know, device startup code that's been tested and, and, fully functionally validated by our, our software teams, as well as some, you know, sort of table stakes middleware things, TCP IP.

or some motor drivers, some things that most applications will leverage. And then at some degree, we do some application proof of concepts. But what we try to do is provide this development kit to the customers in a fully tested production level software quality so that then they can take that and begin their own development into their products.

Jacob Beningo (05:39.982)
All right, excellent. And then that certainly saves them the time of having to write all the low level drivers and kind of become a master of the microcontroller, right? As experts, you guys have kind of built all of that yourselves and then you're kind of providing that nice layer for folks to leverage essentially. So very cool. Now, as I kind of mentioned, I've seen some big changes from the way the SDK was, let's say even six months ago with the new SDK that just came out recently.

Can you share some of the differences of how you guys have been modernizing the SDK today versus what you used to do?

Kyle Dando (06:16.726)
Sure. So two years ago, about two years ago, we met globally to do a strategy session on our SDK. We probably had not done any major SDK architectural changes for five years. Most likely 2015 was the last time they did a major restructuring architecture of the SDK. So it was time and our software

Teams, also customer feedback, had told us that they needed some more modern delivery methods and some modern hooks inside of our SDK that were missing. So we met two years ago. There were really two primary changes that we wanted to make. The first was accessibility. So our SDK was reliable. It was consistent. But it was delivered mostly through the archive zip package.

And that was fine. Most people could get it. And as I said, they appreciated the consistency. But when they wanted to share it, or they wanted to do version control, or they wanted to include in maybe some automated testing DevOps, it fell down. And it required a lot of manual intervention. So that was our number one goal, was to fix that improvement. And then the second one that really drove us was Zephyr.

And we support many different software ecosystems and requirements from our customers. But NXP has seen, and I think the industry's seen, a big increase in interest in Zephyr. And so we, two years ago, decided we wanted to align our SDK with Zephyr and really other open standard ecosystems. And we saw that the changes we needed to make

we're required to support that. Primarily moving to focus on CMake, Kconfig, restructuring some of the SDK to make it more atomic and not a lot of bloat.

Kyle Dando (08:26.368)
So there were some things like that that we did. So those were the two primary. We did quite a bit, obviously, but for this initial conversation, those were the two primary reasons that we made changes. And those were the two things that drove most of the things that we can talk about.

Jacob Beningo (08:42.03)
All right, excellent. And I know me personally, I've noticed a difference between the two, because I know a year ago, I tried to just do some stuff with CI-CD in the old SDK. It was certainly doable, but it required me to really modify my workflows versus the new SDK as I've been playing with it. I've noticed that it's far easier for me to follow the workflow the way I like it to be able pull those types of things in. So I think the changes that I've seen already so far have been actually fantastic. Not that.

You know, you need my feedback on that per se,

Kyle Dando (09:12.588)
Sure. Hey, Jacob, I get a lot of feedback.

Jacob Beningo (09:18.902)
I bet you do. um, no, some of the, some of the stuff that you've talked about, um, you know, kind of from that list right there already, you know, I, I heard you mentioned kind of aligning with Zephyr, uh, kind of seeing the industry going in the direction of Zephyr. And I think certainly a lot of folks have been kind of very interested in Zephyr and adopting it. Um, you know, one, uh, area that you mentioned as well as CMake, um, can you tell us a little bit more about, you know, why kind of.

Kyle Dando (09:20.362)
Yeah.

Jacob Beningo (09:46.668)
You know, why adopts CMake over maybe some of the other options out there? What kind of things maybe made you guys adopt CMake as kind of your build generator?

Kyle Dando (09:56.074)
Yeah, so try to keep it simple, but also explain the benefit and the rationale. That's probably what a lot of customers want to know is like, why did you do it and what is the benefit? So the reason we chose CMake, we had tremendous customer feedback in our support channel.

Jacob Beningo (10:10.492)
Exactly.

Kyle Dando (10:21.514)
and they would constantly be engaging our software engineers on our CMake support. And the problem we had was our CMake deliverable was auto-generated. It was sort of a byproduct of our primary focus. And so our developers had less understanding of what the output was. They just knew that when they hit the generate, it would generate all these support files. So what I mean by that is,

If there was an error in the CMake files, they didn't know anything about it. They would have to really spend a lot of time re-educating themselves in that output. It wasn't machine or it wasn't user readable. A lot of it was generate button, not readable. So we needed to make it to where that was the primary deliverable of our team, CMake.

The reason being is that we saw most of the large customers that rely on builds to auto build, UI independent. They wanted to have that CMake interface. So when they did go to our support teams, we've got an increased amount of tickets and they were unable to support it. So one, big customers require that universal build outline. And then our team had to support it better.

So we see now our developers are developing their primary deliverable as a CMake constructed project using our software. So everything that they deliver as an example is built using CMake. And as you've mentioned and as some of our listeners know, it allows it to be system agnostic so they can use it in different build environments. It's not dependent on a specific.

operating system or a tool specifically. As long as you have CMake properly set up on your system, you can use it in different environments. So that's the main reason we switched to CMake was, as I said, most customers were asking us to answer questions. And then to the universal nature, the fact that it was on multiple platforms, didn't tie anybody into one tool. And we could just focus on one thing.

Jacob Beningo (12:34.798)
Perfect. Yeah, I appreciate that. and for people listening, I mean, there's some key things that I hear there, right? Portability of software, which is really important. And also I'll kind of just point out the demand, right? For CMake, which kind of gives you that underlying trend of, you know, yeah, we can write our own make files. There's certainly different technologies we can use to, you know, to build our systems, but overwhelmingly more and more CMake is really kind of a core technology that everybody is using. And so.

I just want to kind of highlight those two things so that if there are people that are listening, it doesn't mean everyone has to jump on board, right? But it gives you a feel for here's some trends. And usually, you know, guys like Kyle, they start to see those trends before maybe the rest of us in the industry get to see them, right? And so it's just something I point out.

Kyle Dando (13:19.68)
Yeah, one other, this is more my own exposure. So when I would go and work with third parties, so this is other vendors, you they work with five or six semiconductor manufacturers, right? So they have a component, they have a software component and they come to NXP and they say, we want to integrate this into your portfolio. We want your customers to be able to use our component.

Jacob Beningo (13:33.645)
Okay, yep.

Kyle Dando (13:47.04)
And they'd ask us, like, how do you package our software into your system?

Kyle Dando (13:53.862)
So many times these engineers would come to me and they'd say, well, do you support CMake? And I'd say, well, we kind of, it's one of our five things we support. And at the end of the conversations, I felt like they were saying, well, you kind of support CMake, right? Well, now when I go to these third parties and these valuable software components, they can, within a week, they can see our CMake.

architecture and they can see how they can add their components into our projects, into our SDK. It makes it lot easier for customers to get other people's software, not just NXP software. So portability, like you said, but also the ability to make it more modular and allow people to just plug in other people's software and not depend on NXP to stitch everything. I that was really scalability. We had to...

We had to take so many other people's deliverables and stitch it into our generator or our project formats. And it just became inefficient.

Jacob Beningo (14:56.812)
OK, perfect. Yeah, those are great points. I really appreciate that. I know the listeners certainly do as well. So we've talked a little bit about CMake. What about some of the other technologies that you mentioned there? think before, I heard you mention a little bit about KConfig and about West and kind of adopting kind of the Zephyr idea. Can you share a little bit about?

Maybe first of all, what is kconfig and West and how does that fit into the overall SDK? What does that allow us to do as developers?

Kyle Dando (15:31.936)
Let's start with West, because that's got a lot of meat on the bone just there. So West was a tool developed by Google, primarily for the Zephyr project, probably internally, but then they applied it so they could be more efficient in this open standard. What I believe West does is it does a really good job of managing a vast amount of software, right? And it allows an ecosystem.

or a developer to pull in software from multiple sites, multiple repositories. And it manages the source, but also the version. It can organize the software into folders and into a structure that's easy to track and share. And so that was what West was used for. And it's used in Zephyr to define a manifest, what I like to call the cooking recipe.

that can be used by anybody. And when they open up that West file, it's a YAML file, it has a very specific set of ingredients that are very specific, where you get it, what the version is. And we didn't have that open standard way of communicating that information to customers in the past. It was all in a custom NXP recipe. So every time you cooked with NXP or ST or Nordic or Silicon Labs,

you'd have to have a new cook that would have to re-inspect the recipes. And now with West, you can work with pretty much multiple suppliers. You can work with multiple software suppliers. And you all are cooking from the same recipe every time. So that's why West is very important for us. And it allows us to use GitHub as the primary deliverable or delivery source for our SDK. And West will...

allow us to include or exclude our software as we have tested or as the customer requires. So that's what West is at a high level.

Jacob Beningo (17:39.47)
All right, perfect. So then like the new MCU Expresso SDK, it's really broken up into multiple repositories now that then people can specify through their West configuration as to what it is they actually want to pull down and use from the SDK.

Kyle Dando (17:52.97)
Yeah, so two things there. Sorry, I get excited when I talk about this stuff and sometimes we go back and forth. But yeah, there's the ability for them to specify all our sub repos. So it allows us to delegate or distribute the workload and really give that autonomy to that group.

which is super important. It's really hard, it's extremely hard to, at a company like NXP, manage over 50 different groups and to get them all to hit that sequence, right? Time sequencing, people hate, right? Everybody likes the ethernet. We're done with Sonnet, right? Pack it, yeah, so.

This allows people to develop their software in a sub repo. And then West allows us to take that software and put it into a larger package. It's really great allowing people to do that. The second thing that it allowed us to do is deliver all of our software on GitHub.

Before we had some of our software on GitHub and some of it was through packages with West and with GitHub. We've now consolidated all of our software into our GitHub release and GitHub sub repositories.

Jacob Beningo (19:18.734)
Perfect. Fantastic. So from there, that gets us a little bit of a discussion about West and an idea of what folks can do with that to use the SDK. I'll kind of maybe throw in there. You can actually just because it's, you can also use the West with your own software as well and kind of package everything together with West in your own builds as well. But I guess that aside, we also mentioned kind of KConfig. So do you want to share a little bit about kind of what KConfig gives developers?

For those kind of maybe strictly firmware folks, the idea of kconfig might seem a little bit strange to them.

Kyle Dando (19:55.604)
Yeah, and I am not the KConfig expert, but I am the KConfig observer. So let's see what the comments in the podcast stream are. So it is what it sounds like. It's a configuration file or set of files. And it allows NXP or as I said, other software vendors to create a set of configuration values that

Jacob Beningo (20:03.296)
and that's perfect.

Kyle Dando (20:24.116)
can be modified or set based on a project, based on a set of requirements by a user or a middleware. So what that allows us to do is we can provide the software and then pop open a KConfig UI, or maybe just the customer's more savvy with KConfig, like it's a big Linux configuration tool.

use kconfig to configure all these different elements within the software that have parameters that can be tweaked. And that used to be in Eclipse or in IR or in SimSys or in other delivery methods, as I said, a proprietary way to go into those project files and see where components were being configured or dependencies.

Things like that. And now with kconfig, it's a standard way of communicating dependencies. It's a standard way of communicating parameters that can be set. And then you can use a standard way of setting up a project for your requirements if that phi or if that UART or if the free RTOS heap.

It's all done through a UI. You don't need to go into the code and set defines and go into crazy configuration menus. It's pretty easy to set kconfig values to customize a project based on what the developer has set as user definable values or static values.

Jacob Beningo (22:07.406)
All right, perfect. Really appreciate you explaining that to everybody. I think that's a fantastic explanation there. So now we've kind of talked about the major, major pieces there. think that probably make up the SDK. What do you see a typical workflow looking like for developer that would be working with, know, MCU, Expresso SDK, for example? What does that workflow look

Kyle Dando (22:30.72)
That is a tough question. And this is where I wrestle with our own internal and external audiences. Because there's not one workflow that I evidently have to satisfy. We literally are satisfying several different workflows. But let me pick two. Let me pick two. The one is command line. So command line, these developers, they don't need any assistance. They...

they can do everything from a terminal. So they appreciate the fact that now they can get our SDK that has these CMake, kconfig, West fundamentals. And those are very command line friendly. They're able to run commands, configure the project.

from a terminal value or as I said before, they can edit files and then hit builds and launch them either automated or quickly on the command line. That's the typical flow for probably, let's just say half, half of our customers. As I said, they're probably the more advanced large software teams that this is what they do eight hours of the day.

So they don't need all the fancy frills. They just sit there, they're editing code, they're hammering out some command line rebuilds, or they hit a build, go have some coffee, come back, see if it passed. That's the number one. So our SDK now supports that. When you get our SDK, as I mentioned at the very beginning, we were trying to make this atomic single SDK that if you downloaded it, you could extract it and then start running these West build, West.

Flash West debug, there was no dependency on anything else for your flow. That was number one expected experience. The second work experience is our VS Code, more of the integrated design environment, where some people want assistance or they like the benefits that VS Code offers in other ways, code completion.

Kyle Dando (24:45.036)
but also they can do keystrokes and editing and some of our wizards that we integrate in our extension allow them to debug at a higher level. They can inspect objects within their project. So I think having the ability for a user to use Visual Studio Code, get our SDK, have Visual Studio's extension, import the SDK,

add a project by looking at the CMake infrastructure and the Kconfig in the West, they can pull in all the right information for the user. And then all they have to do is hit a build icon, and it will pull in the right files. It will build the project and then flash the board and ultimately, hopefully, have a very quick debug cycle. those are the two user experiences.

The primary change that's happened in the last six months is when we launch a build, we are looking at CMake to get all the generation and the project specifics. We use West to get the source. And then we also use West extensions to do some builds and some flash and some debug. So that's the big change. But whether you're doing it from command line or Visual Studio Code, CMake and kconfig,

have made it a lot more universal. It's easier for, I think, software developers to look at our projects now and say, I see what you're doing. And I can now modify that for my own custom application. it's a very similar flow for whether it's a command line or a Visual Studio Code UI.

Jacob Beningo (26:33.742)
Perfect. And I'll admit, I'm one of those weird developers who fall into both workflow categories, depending on the day and my mood. Sometimes I'm in Visual Studio Code working, sometimes I'm at the command line and I don't know, I can't pick one. It's very much, but what I've played with the SDK so far and with Visual Studio Code is really very easy to bounce between the two, both workflows. a very, I think, well-defined set there. So yeah, so it's very cool.

Kyle Dando (27:01.697)
Yeah.

Jacob Beningo (27:04.526)
So yeah, thank you for kind of sharing how those couple of workflows that are available to folks. So what do you think in general, do you think if someone is already using the old style SDK, how does their migration path look? Are they going to struggle lot? You see them having a learning curve to learn some of the new tools. How does that migration path look like for most folks, do you see?

Kyle Dando (27:31.252)
Okay, good question. So we've tried to make it as uninterrupted as possible. When we met two years ago, one of the key things was we want to move forward, but we want people to come to us at their own pace. So one requirement was that our archive, our traditional SDK package did not change.

So what that means is even though we've moved our primary deliverable to be CMake and Kconfig, we still kept that generator that I spoke about at the very beginning. And rather than generate the CMake, it's generating the old formats. And so if the person was using an old folder structure, they're using an old IDE or a different ID, we still provide them with that older archive zip file.

And they can work within that environment from the same source code, but it's generated to provide them that user experience. So if they want to stay in the zip file, or if they want to continue to develop outside of VS Code in IR embedded workbench, or they want to use the MCUXpresso IDE Eclipse version, they can still do that. So minimum disruption for them.

For the people who migrate, I think that the main differences will just be understanding the CMake components, how to add CMake objects to their project, what files are being changed. So we do have a CMake software module wizard. Otherwise, they can manually manipulate the CMake project files. I think that will be the biggest.

change for them. Understanding kconfig and where it's used would be something that they'd have to understand. But to get started, if they use VS Code or even if they're using the command line, we've made it pretty easy for them to just click those buttons. And then once they have that positive experience of building a project, they can then look at the workspace and really start exploring

Kyle Dando (29:52.486)
the files that are required or the files that change based on their project. as I said, if they want to add a software component, they can use some of the wizards and they don't have to get into the raw files. And then just as far as we did make some changes that we've gotten some feedback from customers. Every once in while, as I mentioned, we haven't done a lot of SDK changes in quite a few years.

Jacob Beningo (30:07.979)
Okay.

Kyle Dando (30:22.348)
And so we were on a, like I said, four or five years with very little change. And I think that's why we got a lot of the feedback. But what we did is some housecleaning. So we had a lot of replicated files. We did some internal tests. I'm sure our customers had done tests where if you scanned our SDK, you would run into some instances where a file was in it 50 times. And then the file, the...

Jacob Beningo (30:35.651)
Okay.

Kyle Dando (30:50.112)
the SDK was so large, so we were trying to satisfy customers' requests to make it smaller, but we had so much redundant files and code. So we really took an effort to create common folders, to use a single example that has unique board files versus replicate everything for every board. So those were changes that they might find, but I think if they...

they really look at it, and we've talked to several customers, they'll understand why we made the changes. They're just frustrated that we moved the cheese, right? They have to spend the time and say, okay, I totally understand why you did that. It's just caused me a week of trying to transition to the new SDK.

Jacob Beningo (31:28.792)
Yeah.

Jacob Beningo (31:41.006)
Perfect. So it sounds like it really probably for most folks, it's it can be a very seamless or very low, very little learning curve really to get up to date with the latest SDK. And so and I'll kind of attest here a little bit to folks. I've played with both versions, kind of experimented myself, which is why asked Kyle on because I really like the direction that the tools went. You know, I've got 20 years of 20 plus years of experience and I didn't find it to be terribly difficult to make the adjustments. Yes, there's.

Certainly little things where, I got to go learn about this. But in a dynamic field like the one we work in, that's to be expected, a little bit of learning, which I think is good for the brain anyways. But one other question I have for you, I know we're probably getting close to time here, but I wanted to ask you, what kind of things can we expect in the future? What do you see? can be changes coming to the SDK. It can be some trends that you're seeing. Maybe they're coming up in the next several years.

for build systems, for the embedded systems industry in general? What are some things that you're seeing that we can maybe expect to see in general? And I'm combining several things there. Sorry, I have a bad habit of lumping it all over.

Kyle Dando (32:48.776)
Sure, sure, sure. So I can tell you some of the things that are going to make NXP better than all our competitors. I have many friends. I think I know my counterparts for all our main competitors, so they're probably listening to me. Maybe not. So I can share a few things. So one thing we want to take our very popular MCUXpresso SDK builder.

And we want to modernize that for GitHub and West. Right now it supports the zip archive packages and customers love it. They go in there and they're able to explore our software components in a very visual way. And then they're able to, as I said, make a recipe and then they get a shopping cart. I look at the zip archive as a shopping cart and then they extract it when they get home.

what we want to maybe transition to is having that be, as I said, more of a recipe of a West manifest. And so I think that's something that they'll see. And that will improve the learning curve of people understanding West and integrating that into their flow. The second thing is with our VS Code extension. So we see Visual Studio Code as

Jacob Beningo (34:06.094)
All right, perfect.

Kyle Dando (34:15.658)
the most popular platform for people to develop software. It's proven by statistics, but our feedback we've received from customers is they like the speed, they like the ability to edit software in a modern environment, and they like the support that we're able to give them with our widgets. So I think what I want to bring is that you've already seen we support Zephyr, we support Matter. We just released Matter support three months ago.

We're going to add a Liro support. So as these new environments are introduced, our CMakeKConfig infrastructure is now going to allow NXP to quickly provide support for those new build requirements. Because they all, unfortunately, they don't work together. And they all come up with different requirements.

I think our flexible new architecture will allow us to support those. So I think in the future, that's where we're spending our time. As customers come to us with new operating systems, new ecosystems, we're adapting using VS Code to provide that improved user experience. So I see that as the improvement.

And then the last thing that you've been spending a lot of time on, it's not really new. I just think it's gonna be an absolute requirement is sort of the DevOps side of things that continuous integration. changed our, one of the things we didn't touch on was our GitHub repository is now a mirror of our internal code base. So that's important because...

when a customer gets our software now, they are working with the same source as our developers are providing. There's no line here, there's a line here. That's important for the CI CD, right? Where a customer now is able to get the version of software that they want. They're able to do nightly builds. They're able to lock a version based on a SHA. It's not a shared file or...

Kyle Dando (36:25.714)
heaven forbid they took a zip file, they used their internal management system, and somehow they now have to patch in changes from NXP to a detached version of software. So I think that is going to be huge in the next two years, where if you're not doing that in two years, people are not gonna be, they're gonna ask you why your software is so...

excluded from normal practices. that's really, think those would be my three things. It's maybe lackluster, but I think those are enough for the audience to see where at least NXP is focused.

Jacob Beningo (37:03.788)
Yeah, absolutely. No, I think that's fantastic. I think it gives them some ideas to see where you guys are at and what kind of things are coming down the path and the types of things that they should be looking at, you know, as well and be expecting. So I really appreciate that. So any final, know, Kyle, I really appreciate you taking the time to chat with me today and to share your insights and kind of what's been going on in the build system realm and and how what NXP has been doing and seeing. Do you have any final thoughts that you'd want to want to share with us before we close out for the day?

Kyle Dando (37:34.08)
I just like every single listener to evaluate our offering. With the Visual Studio code, it gives you a quick...

access point to evaluate this new SDK. You're able to quickly import the GitHub repository using West and then see the new build experience, see the new way of adding software. So I'd like everybody that's interested to invest time, download Visual Studio Code, then follow the installation path to import that new

GitHub SDK, and then start developing and then provide feedback to NXP. We are definitely making changes for improvement, but with any change, there's always tweaks that have to be made. So we really would appreciate the listeners providing candid feedback, constructive feedback to make the MCExpresso SDK better.

Jacob Beningo (38:34.414)
Perfect. Absolutely. And yeah, I certainly would recommend it to everyone as well. You'll certainly get to see what a modern build system looks like, see some of the stuff that NXP is doing, which has been fantastic. You guys are great at listening to feedback, I know, because as you know, a year ago, I was working with some CI CD stuff and I kind of reached out and said, hey, I'm trying to do this. This is really weird. And you're like, hey, this is coming and gave me some good feedback to guide me along the way. so, and now I'm.

Kyle Dando (38:56.854)
Coming.

Jacob Beningo (39:01.696)
integrating these new changes into that project. So I guess I'm saying you guys are listening and making the adjustments, I think, to modernize software and keep our tool chains up to date. So we really appreciate that for sure as users. And I think the listeners will see some great things that you guys are doing. all right. So with that in mind, thanks a lot, Kyle. We really appreciate it. And we'll look forward to talking with you again in the near future. So yeah.

Kyle Dando (39:28.01)
All right, thanks for having me on Jacob. I appreciate it. It was a lot of fun.

Jacob Beningo (39:32.062)
It's fun here as well. So thanks. I look forward to talking to again in future.

Kyle Dando (39:35.02)
All right.


People on this episode

Head Shot

Jacob Beningo

Host